| 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
On Fri, Feb 15, 2008 at 12:57 PM, Jim Sermersheim <jimse@xxxxxxxxxx> wrote:
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