-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Provisional listing. To be updated in the future.

As ever, I'm ready to help to implement this, if you ask.


1. Be able to play with threads in the same "safe" ways that Durus
pre-3.5. (would be nice if available in durus 3.5.1 :-)

2. Fully implement "self.storage.sync()" support in
serverstorage/filestorage. This implementation (currently partially
done) would allow:

- - Notify clients of objects garbage collected, to update their cache to
a) reclaim memory early and b) to avoid "resurrecting" a dead object
(for example, keeping (incorrectly) a nonpersistent reference around).

- - Several serverstorage instances in a multithread server could share a
single backend instance (if it is thread-safe). You could use a server
instance for client, for example, allowing multiple read requests in
parallel (if the backend allows). The syncronization point would be the
backend (inside the "begin" method), so commits would be serialized
correctly.

- - Be able to "replicate" a durus storage via the backend ability to
propagate changes to other (remote) processes. For example, BerkeleyDB
supports replication natively.

- - Be able to deploy durus "cache only" storageservers: the storage
backend would be a durus client of another "real" durus server. That
backend should be able to propagate invalidations upstream to its clients.

3. "connection.get()" does two database requests: one to get the object
type and to create the ghost object in cache, and other access to
actually populate the cache when the object is "touched". This is not
usually a problem because the only object requested two times is "root";
all the others are reachable from there, and when traversing links we
already know the next object type (in fact, that object would already be
a ghost).

Nevertheless I sometimes use "connection.get()" like a "weak reference"
between objects. That is, instead of keeping an object link, I keep an
object OID and then I try to access it just like a python weak
reference. This "weak reference" doesn't preclude the object of being
garbage collected, like usual "weak references". The usage case is the
same that python weak references: keeping references to objects without
precluding garbage collection.

I feel that needing two database accesses is an actual bug masked by
current durus usage profile, but revealed by my "weak ref" pattern.

6. (recovered from Durus 3.5 wish-list) BTree objects need a "changed"
method. I hate to do "a[b]=a[b]" to notify the persistence framework
about changes in "a[b]" when it is a non-persistent container. I've had
problems with some of my junior coders removing such a "redundant" code
because "it does nothing". Argggg!.

All other persistent containers have a "_p_note_change" method. Simetry
applies :-).

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea@jabber.org         _/_/    _/_/          _/_/_/_/_/
                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRRQqGJlgi5GaxT1NAQIVxwP9EZQTCRCrN62sryuQ746a+2Aoi1WzWNNp
VgzTA5NbHWnld3SWmTpfcdzEMK/FPT+lPufM8Wk28cHZkpTESQ4XsWPXmaDgjhVb
xjWSMPf88bYJl/2ghPghlPQAkG5XKXqpkJp0um4QVyLW42nWApjaPG5SykvtRhbo
x74HgWrMEsw=
=9TOV
-----END PGP SIGNATURE-----