On Jul 10, 2006, at 12:42 PM, A.M. Kuchling wrote:

> On Sat, Jul 08, 2006 at 05:15:29AM +0200, Jesus Cea wrote:
> .....
>
> Thanks for your careful analysis; I'm updating the patch to take
> your comments into account.
>
> Responding to your two e-mails:
>> Will this code be included in Durus 3.5?
>
> That's up to David.  I'd like to craft something he finds acceptable,
> which is why this patch is going through several cycles of revision,
> but he's still free to reject the whole idea.  (In which I'll just
> maintain a patched version for our product build...)

Here's what I want to do.  Release 3.5 without any of these
changes.  Plan to include the 'B' command in 3.6.  I haven't had
time to study this implementation yet, but the basic idea of the
'B' command is what I'd like to see in 3.6.

I want to try a revision of the client side with a little more
destructive refactoring than in your patch.  In particular,
I think we might change gen_oid_records() everywhere to produce
a sequence of oid, record pairs that are reachable from some
initial oid (with default of 0).  I think this could use
bulk loading on the client side and it could be used for packing
on on the storage itself.  I think a gen_oid_records() defined
this way could be used to make page_in() functionality
available as a simple loop that goes through the sequence
and calls a method of the connection to instantiate the
instance for each record in the sequence.

>
>> Could be the quantity something negotiated between the client and the
>> server?. I don't like static numbers, moreover if that numbers
>> could be
>> tunable. Currently to change that value we would need to edit both
>> the
>> clients and the server.
>
> Maybe.  David, do you have an opinion here?  Is this too much
> complexity for your taste?

I think so.