(2010/04/10 15:52), Trond Norbye wrote:
> 
> Sorry for being silent for a bit, but I was trying to think this through.
> I've refactored the code now so that it should allow you to do what you want
> (but in a slightly different way). Instead of providing functions to query
> the individual parts of the item, the core calls a single function to fill
> a structure with all the information it needs. This means that all of the
> members of the old item structure is gone...
> 
> I've got all tests passing and will push the change when I'm done reviewing 
> the change...
> 
> Trond

Thanks for your efforts. It seems to me the right direction.

I understand an item object identified with a key has multiple properties
from perspective of the model.
The value is the most important property of the item. In addition, it already
has cas value and expired time; these are also properties of items.

It seems to me the new get_item_info() interface intends to contain various
kind of properties more than bare threes (value, cas and expired time),
because we can easily expand the number of 'struct iovec value[]' in the
new item_info.

If so, I think the allocate() interface should be also modified as follows:

  ENGINE_ERROR_CODE (*allocate)(ENGINE_HANDLE* handle,
                                const void* cookie,
                                item **item,
                                const void* key,
!                               int nslots,             /* # of nbytes[] array 
*/
!                               const size_t nbytes[],  /* # of properties */
                                const int flags);

It enables to suggest number of properties and length of them for each
property slot.
Maybe, we use three slots for value, cas and expired time.
The caller knows what slot is reserved for what purpose.

For example, if slot=0 is reserved for value, and slot=1 is reserved for
exptime, we calls the allocate() method with nbytes[0]=(length of value)
and nbytes[1]=sizeof(rel_time_t).

If here is an intermediating engine module (such as selinux), it can increment
the given nslot before calling the secondary engine, and the added slot will
be available for the intermediating engine transparently.

I'll try to implement a proof of concept patch.

Thanks,
-- 
KaiGai Kohei <[email protected]>


-- 
To unsubscribe, reply using "remove me" as the subject.

Reply via email to