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

[Nataraj Nagaratnam <natarajn@xxxxxxxxxx>]

well, more like..  requirements
to factor in when defining the parameters of CRUD operations to allow the
flexibility.

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

05/26/2006 02:18 AM

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

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

Raj wrote:
 
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. 
I presume Raj, that you mean
what you wrote above in addition to CRUD operations that operate on a single
attribute. 
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_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev