Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] RE: introduction

Hi all,

Sorry for the delay as I was traveling last week.

I have written up an introduction to using the OpenXRI library with sample code at the dev.inames.net wiki:

 http://dev.inames.net/wiki/Using_OpenXRI_Library

which is a companion to the general introduction to OpenXRI page:

 http://dev.inames.net/wiki/OpenXRI

There is also a readme containing dependencies and "deployment instructions" in the CVS repository:

 http://openxri.cvs.sourceforge.net/openxri/README?view=markup


We will also be having a maven pom file soon, contributed by Justen Stepka.

I hope this will get you started. I'll be happy to have a call anytime this week too, let me know when is convenient for you.

Thanks!

=wil


Jim Sermersheim wrote:
I can be available any reasonable time this week.
I agree with Paul, if we can get some sample code and deployment instructions as a starting point, it will save us a lot of time. Jim
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 4/2/07 4:27 PM >>>

Thanks very much Les. See my responses inline below.

------------------------------------------------------------------------

*From:* Chasen, Les [mailto:les.chasen@xxxxxxxxxxx]
*Sent:* Saturday, March 24, 2007 1:30 PM
*To:* Paul Trevithick
*Cc:* Drummond Reed; Tan, William; Sequeira, Ivor
*Subject:* introduction

Hey Paul -

[.]

We had a very productive discussion yesterday. It is my understanding that the current need of Higgins is to be able to perform XRI resolution. As we discussed, this is the ability to query a XRDS to get down to a single SEP. Once that is done the Higgins libraries can then map the various SEP service types to particular functions within the libraries. This is something we can easily help you with as it is simply being able to make use of the openXRI code base. Yes. There are essentially two cascading levels of registries in Higgins that will use XRI resolution. We fully expect that we can just plug use openXRI code for both.

Wil will prepare a short write up that shows your engineers how to incorporate openXRI into Higgins.

This would be invaluable. Jim Sermersheim (cc-ed) is a Higgins committer and the IdAS Component owner. He has some hours here and there over the next few weeks to work on this. Jim and I talked today and agree that having some sample code from you guys would make Jim much more productive. If at all possible I'd like to suggest a quick introductory phone call between you, me and Jim tomorrow (Tuesday) morning or afternoon or Wed morning. Jim is on Mountain time (in Provo).

We also discussed the needs of various enterprises, such as Novell, to be able to run XRI authority servers either locally or within the borders of the enterprise. This is also a core part of the XRI architecture. We fully expect that enterprises will run their own proxy and authority servers similar to the way neustar runs xri.net (a proxy server), equal.xri.net and at.xri.net (both authority servers). The proxy server is simply running instances of openXRI so this is very easy. The authority server is something that is lacking on the open source side. We have a couple of open source authority servers listed on dev.inames.net but they are both very lightweight servers that just read from the file system, not very robust. We run a proprietary one at Neustar that is architected for our environment to be robust and fast. Since it is architected for our needs it does not really make a useable open source application. I am open to talking with any organization that wants help running authority servers. If I understand the distinction between "proxy" and "authority" (top level) servers, I suspect that all Higgins needs to get going is a proxy server. Since the IdAS registry (that would use XRI resolution) is essentially a core Higgins configuration mechanism, its is necessary that it can work when disconnected from the net, on local host, within a LAN, etc. You also mentioned the need to be able to query a local server disconnected from the NET (both internet and local net). Wil and I discussed this a bit more and it gave us an idea. Where it is possible for a pc to run the required http server, in order to run one of the existing authority servers, it is hugely inefficient. We think it would be a good idea for us to extend the 'hint file' capability in openXRI to be able to store XRIs on the local file system. This means that openXRI, given an input XRI, would first query the configured local store then if the XRI is not found or is expired it would query the configured remote servers. The remote servers would most likely come in two flavors. First try an enterprise server (probably proxy resolver but maybe authority server) and if still not found or expired then try the configured global authority servers.

Sounds reasonable.

I also think we discussed the possibilities of having a globally resolvable metadata repository that maps service types to globally available web service routines. The example we talked about was something like xri://$sql which would resolve to an XRDS document that has SEPs for various SQL library routines such as JDBC. Another example could be xri://$openid which might have a C and java SEPs for routines that can do openid authentication. I think this is something that deserves further thought.

Yes. I have not yet updated http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B to reflect our conversation. But I will in the next 2 days. Jim, the jist of it was to unify the "Locally Deployed Context Provider Registry" <http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B#Locally_Deployed_Context_Provider_Registry> with the "Context Provider Registry" <http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B#Context_Provider_Registry> such that both used the same structure (both were XRDS documents) and if a search in the former failed we would then search the latter to find the CP (IContextFactory class name).

We have it on our plates to work on anther version of openXRI once WD11 completes. I am expecting that WD11 is going to close out within the next couple (three) weeks. Unfortunately I think at this point the next release will be a couple of months out. I think a lot of progress can be made at Higgins using the current one and we are definitely here to help that effort.

Yes. We'd like to use the current openXRI codebase.

[.]

Thanks

Les

contact: =les <http://xri.net/=les>

sip: =les/(+phone) <http://xri.net/=les/%28+phone%29>

chat: =les/skype/chat <http://xri.net/=les/skype/chat>

------------------------------------------------------------------------

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



Back to the top