Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] IdAS Capability Discovery

I agree.  For the way IdAS is today, we'd probably want to introduce some API like URI IContext.getSupportedFeature(URI feature) (feature may be null which returns all).  Then we'd define a bunch of URI's which represent supported features.
 
Whenever I think about this topic, as well as forward compatibility I keep wondering if a better model would look more XML-ish.  Each operation taking an XML or DOM argument which conveys all the aspects of the operation.  Seems like an IdAS 2.0 kind of thing though.
 
Jim

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 4/20/07 10:14 AM >>>
In that thread, we also need to discuss how we'd help IdAS consumers deal with the inconsistency of an interface not supported or not completely supported by every Context Provider.  The primary example in this case being an LDAP store where atomicity can only be guaranteed on an entry (DS) boundary.  There are probably many other pieces of functionality like this as well where we'll need to work out a way and instill the habit in IdAS consumers of doing capability discovery.  Transactional support may be a good one to create general capability discovery around.

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/20/2007 8:51 AM >>>
David,

In an earlier proposal, I had placed it at the IContext level and we ended up spawning a transactions subthread which was sort of derailing progress on the update operations issue.  Once people see transaction semantics across Digital Subjects, they then want them across Contexts.  So I was hoping we could table that, address the minimum need for updates, and talk about actual transactions in another thread.

Mike and later others have suggested we think about introducing an ITransaction interface.  You could get an instance of this and pass it to methods which you want to be part of the transaction.
Jim

>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 4/19/07 8:52 PM >>>

Jim,

Sorry to jump into this thread so late in the game. I work for IBM and I support various user repositories that need to be accessed and managed via IdAS. I have some comments and questions about the applyUpdates from the distillation page (a very nice summary, BTW).

Under "Placement of the applyUpdates method", I like the simplicity of bullet 1 (applyUpdate only on IDigitalSubject), but I also have the need to be able to update multiple IDigitalSubjects as an atomic operation. One use case for this is the ability to create a person and add them to a group as a single operation. Would applyUpdate on IContext allow atomic operations involving multiple IDigitalSubjects?  

David

David Kuehr-McLaren
Tivoli Security
919.224.1960




"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
04/19/2007 02:20 AM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions"        <higgins-dev@xxxxxxxxxxx>



To
<higgins-dev@xxxxxxxxxxx> cc
Subject
Re: [higgins-dev] IdAS Update Proposals






BTW, I was referring to this page ( http://wiki.eclipse.org/index.php/IdAS_Update_Proposals_Distillation )

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/18/07 11:47 PM >>>
I've added some method declarations and copious amounts of javadoc-style comments to try to paint a picture of how each would be used. If I have time tomorrow, I'll add pseudo use-case code.
 
A note about the remove() methods; You'll see that I put these at the element to be removed.  I had to pick one way or the other, so I picked this.  We can explore putting remove(identifiedThing) at the container lever if people dislike this.
 
Jim

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/18/07 6:40 PM >>>
The way I envision most of the proposals which have mod methods on each element working is such that the CP will always know the relationship between the element and its enclosing element.  For the LDAP provider, I think the tracking of updates will just be a matter of implementing the mod methods by pushing the mod onto a stack of mods, and then calling ldapmodify when the user calls applyUpdates.
 
I think it will be more clear when I add the method decls, and flesh out a few use cases.  For now, the family is scowling and wants to go to the pool.
 
Jim

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 4/18/07 4:43 PM >>>
Tracking of updates by the CP has been one of my biggest concerns throughout the creation of these alternative proposals.  I'm trying to work out in mind how each proposal effects the complexity of that task for every CP that will not immediately update on every add, remove, or modify.  I should add that I expect the majority of CPs to fall into this category.  Anyway, I'm just considering tracking each update, putting any transactional considerations aside.

I've just re-reviewed each of the alternate update proposals and here's how this issue breaks down:
1. No tracking of updates.  I'm still not convinced that the current list of Cons makes this completely untenable.  Maybe it's missing some.
2. No tracking of updates since everything isn't immediately committed to the backing store.  We actually couldn't do this anyway with an LDAP backing store, even if we decided to ignore the wretched performance footprint that would result.

Everything else includes tracking of updates and some method of allowing both IdAS consumer and CP implementor to know when it's time to apply the changes.  Do any of the proposals or modifications thereof (under 3 & 4) materially change the complexity of the tracking task.  My big fear here is that we are going to place such a large burden on most CP implementors and give each one a house of cards to contend with.  Perhaps some of the proposed methods do make this more manageable but as I read through the distillation proposal, I looked at the bookkeeping involved and I'm worried.

If each IdAS element has add, remove, and modify methods and each element includes an applyUpdates method, then each element has to know who it's enclosing element is so that any applyUpdates can cascade down.  As I modify a value of an attribute, I need that knowledge to cascade up to the Context level so that it knows there's an update to apply unless we place it only on IDigitalSubject.  However the same basic situation persists, every level knows about it's encloser and the highest level enclosure must be notified.

This has gotten me thinking about some sort of change cache and notification interface instead or something that makes change tracking cleaner and more manageable.  Jim's not here to bounce this stuff off but I'll see if I can come up with something to address this concern.

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/17/2007 10:01 PM >>>
I was going to add a 3.b or something like that but started a number 4 ( http://wiki.eclipse.org/index.php/IdAS_Update_Proposals_Distillation) instead (I also changed the main proposals page ( http://wiki.eclipse.org/index.php/IdAS_Update_Proposals) by moving each option to its own page).

Option 4 ( http://wiki.eclipse.org/index.php/IdAS_Update_Proposals_Distillation) is my attempt at distilling and simplifying the existing options along with feedback from the list.  I still need to add the method declarations, but we need consensus on a few things.

I simplified it by breaking it into two required parts (how we specify an update, how and where we specify the application of an update to the backing store)

Then there's a section for optional stuff that we need to agree on (or agree to leave out for now).

Valery, I've probably mis-represented your intent from http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02224.html.

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

Back to the top