RE: [higgins-dev] Constraining a Digital Subject's attributes

[Nataraj Nagaratnam <natarajn@xxxxxxxxxx>]

Does anyone see problems in adding a mechanism
to instruct the context
provider which attributes will be read?

I do not see a problem..  actually,
i do believe we need such capabilities in a way that 'read' method on CPIs
(as we go about defining that interface) to specify what attributes are
to be read. For example, a template of attributes need to be passed in,
so that values can be 'filled in'. Similarly update method would need to
have methods that allow partial updates. There are other use cases wrt
CRUD operations wrt partial operation on a DigitalSubject, or reading a
Set of DigitalSubjects etc for batch processing, etc.

"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

05/24/2006 05:09 PM

Please respond to
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	"'Higgins (Trust Framework) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
cc
Subject	RE: [higgins-dev] Constraining a Digital Subject's attributes

Hmm... have you thought at all yet about how to express
the set of
attributes in this "hint" _expression_? Since the attributes can
be compound
(complex gaggles of objects), there would need to be a way to refer to
not
just "leaf" attributes on a DigitalSubject but also to "branches"
of
attributes. You could think of this hint as the description of a subset
of
the schema of the Context. 

Jim wrote:
> 
> When getting a DigitalSubject from a Context, I think the caller needs
a
> way to (optionally) constrain the attributes/relationships held on
the
> DigitalSubject. Maybe "constrain" gives the wrong impression.
The caller
> needs to be able to provide a list of attributes it intends to consume.
> 
> Given that some context providers will use network protocols to
> gather/produce DigitalSubjects within a context, and given that the
> amount/size of all possible attributes on a DigitalSubject may be
very
> large, the possibility of causing undue performance problems exists
> unless there is the ability of the caller to specify a list of
> attributes/relationships to be associated with a DigitalSubject being
> interrogated.
> 
> Here's an example:
> 
> A context provider uses LDAP as its store. A caller asks for a
> DigitalSubject by name. The underlying context provider performs the
> LDAP search operation to locate and read the named object, and return
a
> DigitalSubject using the information returned.
> 
> Now, the provider didn't know which attributes would ultimately be
> read, so it either: a) read all attributes from the LDAP server, or
b)
> read none, or c) read a few configured ones.
> 
> In terms of avoiding further network traffic, the best bet is (a).
But
> in this case, the provider may have performed a very expensive operation
> as LDAP objects may be populated with large numbers of attributes
of
> large size. OTOH, (b) may, and  (c) will result in the provider
sending
> further protocol requests to gather attributes as they are being read
> from the DigitalSubject.
> 
> Does anyone see problems in adding a mechanism to instruct the context
> provider which attributes will be read?
> 
> Jim
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev