[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: abstracting Entry

At 06:00 AM 2/5/2003, Leif Johansson wrote:
>I am working on the perl-backend and while trying to figure out a better
>way to pass entries back from search operations I realise that it would
>be nice if the Entry contained function pointers (under control of the backend) instead of (or possibly using a union, as an alternative to)
>data pointers. Since there is already a backend-private data blob in
>there the step is not very big...
>
>My reasoning goes something like this: When a backend returns an entry
>it goes through something (str2entry for instance) which produces an
>Entry. This often involves quit a bit of copying. Next the entry is
>encoded for transport in send_search_entry where everything is copied
>to the berbuf! By replacing direct references to data in Entry in
>entry_decode (for instance) it would be relatively easy to create an
>Entry type which would be more effective to pass back from backends.
>In principle it should be possible to skip the encode/decode step
>entierly and call backend-code directly from send_search_entry.
>
>I am new to this list so I don't know if you have discussed this issue
>before. I have done this trick before (in another server impl) and the
>overhead from the extra function calls are insignifficant next to the
>overhead from the extra copying.

I don't recall a specific discussion about this...  but I have
thought (when we're considering hasSubordinates isssues) that some
form of "virtualization" of attribute values might be appropriate...
For the approach to work well, the values returned by the function
would only be used to initialized values.  Another function pointer
likely should be provided (as needed) to destroy the values.  That
is, entry_free() should not assume it can just free() them.

I personally haven't considered implementing something like this
as it would require changing a lot of code.   a_vals is referenced
all over the place...

Kurt