Record keys

[Ivan Gyurdiev <ivg2@cornell.edu>]

(resent with correct list address this time)
> Please help me decide what to do with the record key for the record 
> structures which I've added into libsepol and libsemanage. Stephen has 
> now exported those functions into the shared library, so after an 
> official release, it would be good not to be changing those APIs.
>
> The job of the key is to identify a record uniquely among a collection 
> of the same record type.
> They do this by the record.compare(key) function. Currently the key is 
> required to be a subset of the record fields (so it has to be 
> contained within the record...does that make it useless? could this 
> change in the future, and how?)
>
> ================
> I added the key structure, because it just seemed wrong to pass an 
> "incomplete" record structure containing just the key fields 
> into..say...a query() handler. Note that the key constructor forces 
> the caller to specify all the fields (since this is a key, all fields 
> are required), while splitting this up into set calls to a record 
> structure could result in invalid keys.
>
> Currently keys are contained _within_ the record - they're a subset of 
> the record's fields. That's the primary reason why I ask whether keys 
> should be kept or not - a method called extract_key is supported....If 
> the key can be extracted from the record, you can use that on 
> modify(), and add() to pass a single argument (the record). That also 
> makes it easier for the caller (specify key fields in only one place, 
> instead of both in key and record). It's easy to just add the record, 
> but then the API just *looks* wrong..  also that prevents use of keys 
> that are not contained within the record in the future... but I'm not 
> clear as to whether this will ever change.
>
> If such "external" keys are to be used, then the extract_key method 
> can't be used (but there's nothing to require this method
> for each record - it's just expected internally to be implemented - 
> internals can easily change to fit what's required). Basically, I'm 
> trying to imagine a scenario where the key would not be contained 
> within the record, and what would be required to support that.
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.