From: Scott Lewis [mailto:slewis@xxxxxxxxxxxxx]
Sent: Tuesday, April 03, 2007 6:13
PM
To: Paul
Trevithick
Subject: Re: [ecf-dev] Need advice
for BBAPI refactoring
Paul Trevithick
wrote:
Erkki wrote:
2) The Presence API prefers returning ID-s instead of full objects. For
example, IIMMessage.getFromID() returns ID instead of some kind of User
object. Bulletin Board API currently returns full objects in most cases.
This originates from my own usage of the API -- it was/is mostly used in
a way that usually expects to easily find the posters name and other
details about a post. For example some Velocity templates could be
written to directly reference a message author's name if given an
IMessageBase object: ${message.from.name}.
In Higgins we do have "user objects" called (Digital Subjects) as first
class objects and insist that each must have exactly one "subjectId"
Attribute. A subjectId is an Attribute whose value is guaranteed to be
locally unique within the container.
Hi Paul
I looked at IDigitalSubject here:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.higgins/plugins/org.eclipse.higgins/src/org/eclipse/higgins/core/?root=Technology_Project
Sorry that’s
ancient stuff we don’t use anymore. We’ll delete that eventually.
See IDigitalSubject here http://download.eclipse.org/technology/higgins/idas/lastNightlyBuild/javadoc/
.
And I guess I'm not sure what the 'subjectId' is that you are referring
to...i.e. is it the String returned by 'getName()'? Or is it in some
named ISubjectRelationship or something else?
What I’m
calling a subjectId is the string returned from IDigitalSubject.getUniqueID()
Also, I can't seem to find the Attribute interface (IAttribute?)...could you
let me know where it is/which plugin and package?
In
org.eclipse.higgins.idas package there is IAttribute (see above javadoc link).
Also...how is uniqueness of the subjectId Attribute guaranteed across process?
It is the responsibility
of the Context Provider (plug-in) to ensure that all Digital Subjects that it
serves up are unique. It can do this either by (a) managing its own namespace
or (b) leveraging an existing namespace (e.g. email address namespace, etc.).
A user object (DS) can have N>=0 other
attributes some of which may well also be "identifying" to a lesser or
greater extent.
To my way of thinking in ECF, on the other hand, identifiers are first class
objects.
That's correct. ID instances (implementing
org.eclipse.ecf.core.identity.ID) are objects that are unique within an associated
Namespace...also, they are immutable (cannot be changed).
Note that the ID interface also extends the java.security.Principal interface
and so is *not* intended to be used to represent a 'user/subject' but rather
have a one-to-many relationship with some 'user' object within the JAAS
framework.
Also, BTW Paul...FYI we've gone to a lot of trouble over past six months to
refactor the org.eclipse.ecf.identity plugin to allow it to support as many
runtimes as possible...e.g. only use JRE 1.3 API, no other dependencies on
other plugins, and only the *subset* of the JRE 1.3 API supported in the CDC
1.0/Foundation 1.0 OSGi execution environment. Also it's quite small in
code size (e.g. 30K) so as to not to be burdensome in small runtimes (e.g.
eRCP) and has no dependencies other than on the Equinox common classes...again
to be able to run on as many runtimes as possible.
So the
possibility exists to return from IDigitalSubject.getUniqueID() an
org.eclipse.ecf.identity.ID instead of a String. (which is back to the way I
had things 2 years ago!). What we need is for you to remind us what benefits
there are. I can easily see that it allows for better/stronger typing of these
unique identifiers.
The IUser interface basically presents an extremely simple notion of a user
required for ECF and dependent plugins...i.e. something that is uniquely
identified within some namespace (i.e. IIdentifiable.getID()), and (optionally)
has associated name (getName()), nickname (getNickname()), and a Map of
arbitrary properties (getProperties()). It could very well be integrated
with Higgin's notion of a digital subject, but since we want to be able to run
on CDC 1.0/Foundation 1.0 subset we're trying to keep the dependencies to an
absolute minimum...and so I should also ask: can all the higgins core
plugins compile/run on CDC 1.0/Foundation 1.0 subset?
I’ve cc-ed
Jim Sermersheim of Novell (who is the Higgins
IdAS component owner (i.e. org.eclipse.higgins/plugins/org.eclipse.higgins.idas))
he could answer better than I about dependencies.
Also...if higgins and others wanted to use the org.eclipse.ecf.identity bundle
*separate* from the rest of ECF you could do this as I don't expect that plugin
to change much any more.
Understood.
Thanks,
Scott
-Paul
