Jim, just a note that “XRIs to
identify the things we're asking for” does not preclude using “other types of identifiers” –
XRI is a syntax for structured identifiers that can include any form of
identifier that can be expressed as a string. So you can have an XRI that
includes an XPath _expression_, and the XRI parser handling it can hand that to
an XPath parser as needed to navigate an XML document. The XRI “$xpath”
has been proposed for this. Here’s an example XRI that identifies the
primary resource (an XML document) using a URL, and then identifies a node
within it using an XPath _expression_:
$(http://example.com/example.xml)*($xpath*(/example/budgets/acme/@cost)) =Drummond
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On
Behalf Of Jim Sermersheim
Sent: Friday, February 22, 2008
6:02 AM
To: Higgins (Trust Framework)
Project developer discussions
Subject: Re: Fwd: [higgins-dev]
Nodes outside Contexts?
What
if we created something like an org.eclipse.higgins.sdk package and it had
these kinds of operations? Things that are a little more straight-forward
for non-hardcore IdAS consumers. I could see it being useful to have all
kinds of APIs that are meant to be used in a stateless environment. Rather
than getting a context, and then holding on to that long term, we would have
APIs that perform simple complete operations (like Drummond mentioned: get the
cell phone number of my friend Don). I suppose in a first cut at this, we
would try using XRIs to identify the things we're asking for, but it might be
nice if we allowed for other types of identifiers like say an xpath string as
well.
Jim
>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx>
02/15/08 10:54 PM >>>
- Yes
you're right, I forgot to put in the authn materials. So the proposed new
methods on IdASRegistry would be:
INode createNode(INodeId nodeId, Object authnMaterials)
INode createNode(String nodeId, Object authnMaterials)
- And yes you're also right in that this would only be a convenience method for
the following:
IContext context =
IdASRegistry.getInstance().createContext(nodeId.getContextId());
context.open(authnMaterials);
INode node = context.getNode(nodeId.getRelative());
- I also agree that create* sounds strange. The reason why I originally named
it that way was that the related method in IContextFactory is also called
createContext. Maybe it would be best to rename it all to instantiate*
- Not sure if that belongs in IdASRegistry or somewhere else.. You know that
better than I do :) If it should be in IdASRegistry I'll be happy to implement
it.
Markus
On Feb
15, 2008 9:18 PM, Jim Sermersheim <jimse@xxxxxxxxxx> wrote:
Sorry,
didn't read this before replying to your other one.
The
proposed createNode methods still need some kind of authN materials right? Also,
is it just me, or does IdASRegistry.create* seem like it should be get*, or
maybe instantiate*?
Jim
>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx>
02/15/08 3:42 PM >>>
So maybe we should do the following:
Create an interface INodeId with these methods:
IContextId getContextId() <--- return value may be null if it's a
relative NodeId
String getAbsolute() <--- returns the absolute NodeId which includes the
ContextId, may be null
String getRelative() <--- returns the relative NodeId (that's what used to
be called SubjectId)
Create a factory class NodeIdFactory (in analogy to the existing
ContextIdFactory) with the following method:
INodeId fromString(String)
Add these methods to IdASRegistry:
INode createNode(INodeId)
INode createNode(String)
Markus
On Fri,
Feb 15, 2008 at 1:03 PM, Markus Sabadello <msabadello@xxxxxxxxxxxxx>
wrote:
Nono that's not what I'm saying.
Every node is inside a context.
But: http://wiki.eclipse.org/NodeId_Data_Range says
that "An absolute NodeId Data Range MUST uniquely identify both a Context
and a specific Node within that Context".
This means that the absolute NodeId contains a ContextId and a relative NodeId
(see examples on that page).
So.. If you give the IdASRegistry an absolute NodeId (and auth materials for
opening the context.. I forgot that in the previous mail), it should be able to
directly hand you an instance of INode, or?
Markus
I
want to just say no, but I suspect I'm missing something. Right now,
a Context is like a top-level thing in Higgins. So createContext is
what we have to use to get started -- once we have the Context, everything we
do (including accessing/updating Nodes) is in terms of that Context.
Are
you thinking we need a way of creating Nodes outside the scope of any Context?
>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx>
02/13/08 11:09 AM >>>
Jim,
Should we have an INodeId interface, in the same manner as we have a IContextId
interface?
I could imagine the following method in IdASRegistry:
INode createNode(INodeId nodeId)
.. just like there is
IContext createContext(IContextId contextId)
today.
Markus
_______________________________________________
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
|
