Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] IdAS Update Proposals

BTW, I was referring to this page

>>> "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

Back to the top