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