Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] RE: About OpenXRI 
When NeuStar inherited the OpenXRI code from Epok, the server component
consisted of proxy and resolution server (registry) code. The resolution
server code, however, has not been updated to XRI resolution working
draft 11 because of the lack of human resource and there was no audience
for it (we don't use the resolution server code for the global iname
registry.) Effectively, the server component distills down to the proxy
servlet.

However, should there be interests for the resolution server, we can
certainly revive (or rewrite) it. In any case, it is somewhere along the
roadmap.

=wil

Steve Churchill wrote:


Jim (and Wil),
OpenXRI does contain a registry component, but (1) it has fallen out of use and (2) it does not have a persistence mechanism -- the storage interface has only a trivial in-memory implementation. You would need to add a persistent implementation. I have not visited this code for well over a year, so perhaps Wil can add some more comments about it. 

~ Steve

------------------------------------------------------------------------
*From:* higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Jim Sermersheim 
*Sent:* Thursday, March 08, 2007 7:22 PM
*To:* 'Higgins (Trust Framework) Project developer discussions'
*Subject:* [higgins-dev] RE: About OpenXRI
One of the proposals is to also allow for a locally-deployed registries. For that, I assume we'd need the server package. Or is the server package actually a proxy resolver, and we'd need something else to "serve up" the local registry? 


Jim


>>> "Steve Churchill" <steven.churchill@xxxxxxxxx> 3/8/07 6:52 PM >>>

Paul (and Wil),

Your XRI resolver client Java code will want to invoke the XRI resolver
functional interface defined in Appendix E of the XRI Resolution Spec
(WD10.)

The OpenXRI resolver client package has a Java binding to this. It can be
configured to (a) invoke a "local" resolver where the resolver algorithm is performed inside your JVM, or (b) forward the request off to an "HTTP proxy 
resolver" on another server.
Whichever you choose, you will only need the OpenXRI client package and thus 
you will only need these dependencies. I am sure they are very light.
I have Cc'd Wil Tan of Neustar (the author) to shed some more light on this. 
Wil, what are exactly the client dependencies?

Thx,

~ Steve

-----Original Message-----
From: Paul Trevithick

Hi Steven,

I don't know if you've been following all this, but Higgins is in the
process of re-implementing the IdAS Registries (see [1]). As I understand
it, Tom of Novell and perhaps others are going to start trying to implement 
this stuff. And as you can see it depends on xri resolution.

In parallel Mary and I are looking at OpenXRI from the point of view of
putting together a CQ (Contribution Questionnaire) for Eclipse legal. In
doing so I see that the readme says OpenXRI has the following dependencies: 

   - Apache Xerces (DOM3 for building, DOM2 or DOM3 at runtime)
   - Apache Xalan
   - Apache XML Security
   - Apache Commons Logging
   - Apache Log4J
   - IBM ICU4J
   - JUG
   - JUnit (only needed for test classes)
   - Java Servlet API (for building, server can be deployed in any
                       compliant servlet container)

This raises a number of questions. First, from a legal review work
minimization point of view, do you think that we need *all* of the openxri
code (and thus all of the above 3rd party dependencies)? OpenXRI has a
number of components (e.g. server, client, etc). Do you think we need all of 
these?

If we do need all of these. We will probably need some help doing the
following: (1) tracking down the exact version number of the above 3rd party libraries and comparing those versions with the versions of those components that have already been approved (2) making sure that all of the source files 
have headers, copyrights, licenses, etc.
[1] http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B _______________________________________________ 
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Back to the top