On May 22, 2006, at 7:47 AM, Jesus Cea wrote:
> 1. A better behaviour of the new unix domain sockets when the
> filesocket
> is already present in the filesystem.

I think we will have this in 3.5.

>
> 2. A PersistentString class. I know this can be difficult with things
> like the unmutability or the hash-ability.

This is different from PersistentList and PersistentDict and
PersistentSet
in that we can't make a PersistentString class whose instances do a good
job of impersonating basestring instances.  Lots of functions want
arguments that are instances of basestring, and not just objects
that "quack" like basestrings.

>
> 3. A BIG latency improvement when commiting a lot of new objects. The
> fundamental latency issue here is the "new_oid" burst. Would be
> nice if
> this improvement could be done without losing a lot of OIDs for short
> "connection" sessions, but it is not a requirement. I know that
> suspending a "_persisten_id" call to know in advance how many new
> objects are we commiting is probably not possible. But "persistent.c"
> could probably track new persistent instances not asigned yet to a
> connection (so, new objects) and give that value efficiently. We can't
> suppose all new objects are going to commit in the same connection if
> there are several ones, but we could request a "new_OIDs" count of
> "min(new_persistent_objects_count,100)", for example.

Here's what Roger and I were talking about for this:  modify the
client/server
protocol by having the 'N' command have a 1 byte argument giving the
number
0-256 of new_oids requested.  The response returns that number of oids.
This allows the server to remain stupid on this issue, and the
client can maintain an oid pool if desired.

I should, however, point out that on the type of deployment for which
durus is really designed (mostly read, very short connection between
client
and server), the latency cost of oid allocation is insignificant.

>
> 4. Try to reuse unused OIDs in future transactions. The unused OIDs
> are
> those dropped when a transaction conflicts. Point 3+4 could reuse the
> same datastructures (a pool of unused but assigned OIDs).

The benefit of this is very small, but I think the complexity cost
is also pretty small.

>
> 5. client<->server connections should include a version number, to be
> able to detect mismatched connections automatically.

I don't get this.  What kind of mismatch are you anticipating?

>
> 6. BTree objects need a "touched" 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!.

Are you talking about _p_note_change()?

If you want changes to be tracked in a container, then it should
be a persistent container.  If you are storing non-persistent containers
in a BTree, then your BTree nodes will load whole sets of those
containers
just to look at one.  That might be useful in some circumstances,
but certainly not all.

>
> Durus is great.

I think so too, thanks to Neil, and to the ZODB developers.
We can still try to make it a little better, though.