Re: [higgins-dev] IContextFactory vs IContext instantiation.

["Tom Doman" <TDoman@xxxxxxxxxx>]

Valery,

Jim and I have discussed this item quite a bit, especially lately.  Yes, we do have an example of what we're doing in our LDAP Context Provider.  However, I don't think either of us feels what we're currently doing is completely satisfactory.  I'll suggest this an additional topic for our F2F agenda.  I think it could be a companion topic with the CP configuration topic Jim and I already suggested.

Anyway, currently in the LDAP CP, we do, essentially a one-time configuration and this aspect of it presents no problems for us.  It's the manner in which we're doing our one-time configuration which feels a little hackish to us.  I'll describe it.  We initially planned to take a URI of at least the "file:" and "http:" schemes.  Currently, it only supports the "file:" method.  Anyway, this URI is expected to point to a configuration file (currently of our chosen format, but a general configuration format is the main crux of the topic which has been suggested for the Higgins F2F).  This configuration file contains all the other information we'll need for our implementation of our LDAP CP, namely, addresses, default user credentials, mapping tables, and other policy.

The schema is gotten as requested from the configured back-end LDAP store and dynamically converted to OWL.  Bottom line, all we're doing is using the URI specified in the createContext to get us all the other info we need for the CP to properly function.  We have discussed this on at least one of the weekly calls and I believe this was the consensus of the design purpose of the single URI for createContext.

One of the problems that Jim and I have discussed and would like to have resolved is the continuing nebulous concept of context sameness.  The way we're formulating the URI for the LDAP Context Provider, it could only really be supported by a single context provider implementation unless we come to consensus on the format of CP configuration files which, as I said, we'll discuss at the F2F.

Would you like to have a look at our LDAP CP code?  It's currently out on the bandit site and is LGPL so if that doesn't cause you any IP heartburn, have a look: http://www.bandit-project.org/index.php/Common_Identity_DEV_Downloads in the "Higgins IdAS Context Providers Source" section.  Looks like the latest is not out there, we're around version 250 now.  I'll ask Jim or Duane to update it if you want to have a look.  If that's a problem, it should be checked into Higgins under EPL soon.

Tom

>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 11/15/06 5:09 PM >>>
Hi Jim,

I'm trying to figure out how to implement IContextFactory for our jena
based context provided but I can't really understand how to create
contexts using single parameter provided to IContextFactory.createContext
method.

First of all it is a big question what that parameter (URI
contextRef) really means. Do you have some examples of such
context refs and their interpretation? How are you using context ref
parameter in your implementation of LDAP context provider?

The second problem is that when we're creating some context we need to
be able to set context's schema (preferably either as InputStream or
as URL) but where we can get a schema if IContextFactory.createContext
takes only one parameter?

Next problem is that we need a way to configure somehow actual context's
storage (database connection, file, LDAP directory, etc) for each context
instance but we can't do this without additional parameters in
IContextFactory.createContext.

I do not think that one-time configuration of context factory could
help to solve above problems. May be it would be right to add one more
parameter (probably of type java.util.Properties) to both canCreate
and createContext methods of IContextFactory?

-- 
Thanks,

Valery

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev