Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Context IDs 
If we're at a point where we're thinking of making this extensible, it might also be a good time to step back and decide whether to generalize the IdASRegistry to a HigginsRegistry.

We have other things that have their own "registries" like card providers, token providers, ISS providers (anything termed a "Plug-in" on this page http://wiki.eclipse.org/Image:Higgins-v42.JPG)

So then to build a kind of ouroboros, the "resolver/discovery" aspect of this registry framework would use the registry framework itself to hold a registry of resolvers.

Jim
 
>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 10/12/07 9:48 AM >>> 
Hi,

[Summary of a discussion on #higgins today]

Since now the IdASRegistry can also use context IDs obtained via the
Configuration API (e.g. from an XML file) in addition to the previous three
XRDS-based ways, people are wondering, in which order are these ways tried?
And, isn't this a performance problem (Jeesmon)? And, can we add new ways
and remove existing ones (Mike)? And, is the context ID string deterministic
so we can always know which way is tried (Jim)?

Right now this is handled in a simple way. When
IdASRegistry.createContext(String)
is called, four hardcoded ways of constructing a IContextId from a String
are tried in this order:
1. from Configuration    <-------    This used to be at bottom; I moved it
to the top today after IRC discussion
2. from local XRDS file
3. from XRI resolution
4. from URI

(Remember: A context ID contains everything needed to instantiate a context,
i.e. context type and context configuration)

Now Mike's idea is to make this process configurable / extensible, so that
people can add their own kinds of context IDs. E.g. if you hate XRDS, you
kick this way out. Or you add your own way of storing context IDs (e.g.
database). The idea is to introduce the concept of context ID "resolvers"
(as Mike calls them).

In fact, if done right, this may also be able to solve the other problem I
posted to the list recently (creation of new contexts and new context IDs).
The individual context ID "resolvers" could work two-way, i.e. provide a
method for creating a new context ID (potentially based on an input string,
to auto-generate an "appropriate" context ID, as Jim calls it).

In theory this all sounds pretty good to me. The downside is added
complexity (new projects; a new interface; another mechanism that needs to
be understood; and we may end up having 72814 different ways of using
context IDs, instead of them being just a tiny footnote in the already big
enough IdAS book).

What do people think?

Markus

P.S. For your reference:
http://wiki.eclipse.org/ContextDiscoveryComponents
http://wiki.eclipse.org/ContextDiscoveryComponents_withoutXRDS

Back to the top