[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] new IdASRegistry
|
Jim, thanks for your detailed feedback.. See inline for replies.
On 8/8/07, Jim Sermersheim <jimse@xxxxxxxxxx
> wrote:
Markus,
- that the registry can be used to "Add an already instantiated and configured context factory to the registry". Do we really need this? Does it work in your code?
[Markus] IdASRegistry is using this method internally, and I thought maybe in some esoteric use cases or for testing purposes it might be useful to have it public.
- "IdASRegistry employs a cache, so that context factories can be re-used". When does the cached instance become stale? If the original config which was used to instantiate a factory changes, it would be good if a subsequent access of that factory would result in a fresh factory.
[Markus] The cache is very simple. If it is enabled, the instances never become stale. The idea is that if the IdASRegistry is configured from a local file, you enable caching, since you don't expect the file to change. If you configure the IdASRegistry from a URI or XRI, you disable caching, so every time a context factory is requested, the XRDS is freshly discovered and a context factory chosen, instantiated and configured.
I'll add this information to the page.
Let me know if anyone feels we need a more advanced solution here.
http://wiki.eclipse.org/ContextDiscoveryComponents#Context_Types lists some example context types. Do we think we need an official list of these? Also, if we do plan to standardize any context-specific settings for cases where multiple factories can be used to produce a given context, we should think of context types as the "key" to knowing what the standardized settings would be. One suggestion might be that we simply carve out a place in the higgins wiki pages to document each context type, and the settings which are valid/required to be used to configure contexts of that type. (note that I'm talking about standardized config which one would see in the SEP for a context of a given type, not the context factory config)
Yes we need an official list of context types. This will probably involve the OASIS XRI technical committee, but the process should not take too long. I expect the context types will look like the ones in the examples,
e.g. $context+ldap, $context+jena, $context+openid, etc.
I'll start a separate thread about this in a few days.
I don't know enough about the use cases to judge whether we need to standardize settings, but the idea of having sections on the wiki to document context types sounds good to me.
They are the standard <URI> elements in a SEP. But nothing special, as far as we are concerned.
Like the context configuration, they are just something a context factory can use to instantiate/open a context. A context factory doesn't have to use them. If it needs no URI and finds everything it needs in the context configuration, that's fine. Or if it only needs a URI to instantiate/open a context and no context configuration at all, that's also fine.
- "When the IdASRegistry finds and instantiates a context factory, it checks whether the factory implements the IConfigurableComponent interface...". I think we should change IContextFactory to extend IConfigurableComponent. Then no checking needs to occur, and everyone works the same.
Maybe. I'm sure you know this better than me.
- I would remove IContextFactory.canCreate().
- Yes, IContextFactory.createContext() should take IContextId
- On the third bullet, let's leave this out for now. We can add it if we need to later.
- On the fifth bullet, let's not implement support for storage of pre-defined contexts.
Other than that and the other comments on the list, I think if the CP writers feel it's adoptable, I vote to check it in.
[Markus] Great. Thanks again for the detailed thoughts.
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
