|
is there a bug for this? I've been trying to be better at prioritizing and working out of bugzilla
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 06/26/08 10:36 AM >>>
Let me repeat what I think you are asking for so I know I'm on the same page: Today an attribute selection list is limited to specifying which attributes to return. This is a good start, but even this is not enough to cause a "minimal" amount of data to be returned (in the case where a CP talks over a connection to its backing data).
The proposal is to allow more fine-grained control over the attributes to be returned. Specifically, we want the selection list to be able to point at sub-elements within complex attributes.
Your proposed interface looks to me like it should work for that purpose.
Should we retain the existing semantics? Currently we say that the selection list is essentially a statement made by the caller which expresses the attributes (and now specific parts of attributes) he intends to read. But, if he happens to try to read other attributes those reads should succeed (but performance may be slower due to him not declaring his intent to read them). So, should we keep these semantics? I think we should, but it *may* place a small extra burden on the CP writer (depends on the nature of the CP).
Jim
>>> "Yuriy Pilipenko" <ypilipenko@xxxxxxxxxxxxxx> 06/26/08 7:15 AM >>>
Hi Jim.
Just a reminder. Would You please consider making such a change to IdAS
iterfaces together with others doing recently. I guess this also can help in
ussue spoken out by Deniel yesterday about XDI CP - knowing what exactly
entity attributes it should request at a time.
Thanks, Yuriy.
----- Original Message -----
From: "Jim Sermersheim" <jimse@xxxxxxxxxx>
To: <higgins-dev@xxxxxxxxxxx>
Sent: Monday, May 26, 2008 8:32 PM
Subject: Re: [higgins-dev] IdAS interface questions
Ok, I need to look more closely at this. I'll be on vacation until
Friday May 30
>>> "Yuriy Pilipenko" <ypilipenko@xxxxxxxxxxxxxx> 05/24/08 11:39 AM >>>
Not exactly. Actually we want to call getEntity() once per unit of work
but have provider loaded only needed attribute values of Entity itself
as well as only needed attribute values of included complex values, not
more. Yes, in this case CP don't need to do unnesessary protocol
roundtrips inside (#2).
We propose to change method signature to getEntities(IFilter filter,
IAttributeSelection attrSelection) and getEntity() respectively, where
IAttributeSelection with companion interfaces would be something like
the set of Filter interfaces. Instance of it can hold the tree structure
of only needed attributes and complex value's attributes according to
actual model of Entity and owl schema. It would be something very simple
like this:
interface IAttributeSelection {
addAttribute(URI attrType);
addComplexAttribute(URI attrType, IAttributeSelection selection);
}
Thanks and regards.
Yuriy.
----- Original Message -----
From: Jim Sermersheim
To: Higgins (Trust Framework) Project developer discussions
Sent: Friday, May 23, 2008 10:15 PM
Subject: Re: [higgins-dev] IdAS interface questions
So, I'm not exactly sure what's being asked for. What is the actual
problem?:
1) It takes too many API calls to access all values of all attributes
2) Too many protocol hits happen (inside the CP) when accessing all
values of all attributes
If it's #2, I think there are things we can do about it. If it's #1,
what do you suggest? The fact is that the Higgins Data Model drives the
APIs.
You ask for "interfaces that will not need cycles and big number of
separate calls". I'm not sure how to do this unless we decided to
serialize an entity and it's attributes and values (recursively) into
some formated blob (like structured XML) and return that instead of
objects that need to be traversed. Is that what's being suggested? If
so, what will people do with that? Most people will parse it and then
use DOM APIs to traverse the tree of elements. How is that different
from what the existing Higgins APIs do?
Jim
>>> "Yuriy Pilipenko" <ypilipenko@xxxxxxxxxxxxxx> 05/22/08 10:10 AM
>>>
Hi, Paul.
Yes, inside provider we can get all the Entity information, cache it
and return it by one piece at a call. Ok, when the Entity contains very
big volume of information, such as Attribute with many simple values
(collection), we can narrow the result by specifing only needed
attributes. But how can we limit the needed info if the Entity contains
some attributes with complex values which in turn can hold also complex
values with their respective attributes as well as simple attributes
with collections of simple or complex values wich in turn... and so on.
Such Entities can be resource-intensive when loading in whole.
How can we specify loading not entire Entity but only needed info in
the attributes of complex values? Now it can't be done. It may be
possible when Iterfaces will become changed to use IEntity instead of
IComplexAttrValue and adding probably getEntities(IFilter filter,
Iterator attrSelectionList) method to IAttribute interface for example.
However it still will require one separate call per such an Attribute
with complex values - Entities. In this case provider may not load
Entity's complex values at once when getting Entity.
Thanks and regards.
Yuriy.
----- Original Message -----
From: Paul Trevithick
To: Brian Walker
Cc: Valery Kokhan ; Yuriy Pilipenko ; Jim Sermersheim ; Drummond
Reed
Sent: Thursday, May 22, 2008 2:59 AM
Subject: RE: [higgins-dev] IdAS interface questions
We have had some conversations today about this. In brief there is a
great deal that can be done in the CP t
o vastly improve performance. For
example each call to get anEntity should be fetched from the backing store
with one query and then
this Entity responds from memory to each fine-grained get attribute
call.
_______________________________________________
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
|
