durusmail: durus-users: Re: Trivial doc/interface fix
Trivial doc/interface fix
2006-03-13
Re: Trivial doc/interface fix
2006-03-13
2006-03-13
A new backend storage (Re: [Durus-users] Re: Trivial doc/interface fix)
2006-03-13
Re: A new backend storage (Re: [Durus-users] Re: Trivial doc/interface fix)
2006-03-13
Re: A new backend storage (Re: [Durus-users] Re: Trivial doc/interface fix)
2006-03-14
Re: A new backend storage (Re: [Durus-users] Re: Trivial doc/interface fix)
2006-03-14
Re: A new backend storage (Re: [Durus-users] Re: Trivial doc/interface fix)
2006-03-14
Re: A new backend storage (Re: [Durus-users] Re: Trivial doc/interface fix)
2006-03-14
2006-03-13
2006-03-21
Re: Trivial doc/interface fix
Peter Wilkinson
2006-03-13
On 14/03/2006, at 8:23 AM, David Binger wrote:

> Okay.  I'll add those two to Storage.
>
> It sounds like you are implementing a Storage.
> That's good.

Interestingly just this past weekend I spent a couple of hours being
curious about how storage backends work and in the process put
together a SQLite backend. Rather perverse in some ways but has some
interesting benefits on startup speed and memory consumption as no
index needs to be built in memory, start up on a 3million entry
database is instant.

I'm not sure that what I'm doing is much more than a exercise in
getting a better understanding the internals of Durus, we are looking
to move all our application development to Durus to have been poking
around for a while. I was very pleasantly surprised by how easy it is
to write a storage engine, though one thing that did make the code a
little more complicated and less able to be optimized was the storage
engine being handed already packed and encoded values for oid and
record to store. If the actual oid and instance of the record was
passed down some interesting optimizations could be done.

All up I can say such a small and effective code base is a joy to
experiment with.

Peter W.




reply