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

David Binger wrote:
>> 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.

I am aware of the issues. It is difficult. In fact I tried and finally
gave up and ended encapsulating the string in a (otherwise empty)
persistent instance, encapsulating/decapsulating manually. Too many
issues to solve.

> 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.

The difficult thing here is to decide how many oids to request. I give a
proposal in the previous email.

Is Roger subscribed to this list?.

> 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.

Durus is desirable in a lot of environments, and we are getting to the
point where it is useable there without doing miracles. Conflict
detection improvements in Durus 3.4 is a big big win in my environment.
And the final code is more readable, simple and performing that the old
one :-p. So a win/win situation!.

>> 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.

If you implement point 3 (bulk new_oids), point 4 is nearly "free" :-).

>> 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?

If Durus 3.5 add a "how many oids" parameter to "N", Durus 3.5 and Durus
<3.5 would be incompatible in the cliente<->server link. So, would be
nice if clients could detect that and give up instead of crashing hard,
corrupting your storage or leaving the server in a unstable state :p.

If the server sends its "protocol version" when a client connects, and
the client verifies that it can talk that protocol before doing any
request, live would be more simple.

Durus 3.5 would be a good release to implement this "protocol version
advertising", since the client<->server protocol would be incompatible
anyway.

>> 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()?

Sort of. Other persistent containers includes a "_p_note_change()"
method, but if you do "a[b]._p_note_change()" in a BTree, you are
calling the "_p_note_change()" (if exists) of the "a[b]" object, not "a"
object.

A "a.touch(b)" method would be nice.

> 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.

I'm aware of this. In fact I use it to improve performance when I access
"near" objects or to improve storage compression performance. For
example, in my mailbox server immplementation, each message is split in
several perhaps 4KB long fragments, and stored in a (ordered) BTree. So
a single Btree fetch retrieves several "fragments" and keeps them in the
cache, and a store is more compression friendly. Performance is everything!.

>> 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.

:-). Even if it reaches more deployment profiles that originally
designed for :-p.

- --
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

iQCVAwUBRHHFAZlgi5GaxT1NAQLx5wP9FjOE7B6d59ysN9xyjJexm5PpqDmT5CAE
5wtDGosnaNJCM55Z3xT9QacCbuCSf5y32+ehO99RwZDe1W6BShTIqXf/Vp+b6bOH
C/ZUN6Ru+9cbPvk2a8NSZkzo3JnJaNFEWDMofPeP+7zhKMfxXdl3IGkpui4nseNs
Ntg9UaOWjX4=
=of2u
-----END PGP SIGNATURE-----