Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] RE: About OpenXRI

Let's have a conf call to discuss this. We've set up this call: 

The dial in number for 2PM PT/ 4PM CT / 5PM ET on Thursday Is 1-641-297-5600
passcode 762425

We're expecting: Mary, Tony, Drummond, possibly an associate of Durmmond's
and me. If more folks wish to call in let me or Mary know and we may have to
regenerate the call with more lines.

-Paul


Tony wrote:
> 
> I guess I have IP issues bringing XRI into Higgins. See the OASIS IPR
> statement for XRI which leads you to
> http://www.xdi.org/docref/legal/xdi-org-ipr-agreement-v2-2004-09-13.html
> 
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> 
> 
> 
>              "Tan, William"
>              <William.Tan@neus
>              tar.biz>                                                   To
>              Sent by:                  Steve Churchill
>              higgins-dev-bounc         <steven.churchill@xxxxxxxxx>
>              es@xxxxxxxxxxx                                             cc
>                                        "'Drummond Reed'"
>                                        <drummond.reed@xxxxxxxxxxxx>,
>              03/09/2007 01:14          "Chasen,  Les"
>              PM                        <les.chasen@xxxxxxxxxxx>, "'Higgins
>                                        \(Trust Framework\) Project
>                                        developer discussions'"
>              Please respond to         <higgins-dev@xxxxxxxxxxx>
>              "Higgins \(Trust                                      Subject
>                 Framework\)            Re: [higgins-dev] RE: About OpenXRI
>              Project developer
>                discussions"
>              <higgins-dev@ecli
>                  pse.org>
> 
> 
> 
> 
> 
> 
> 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
> >
> 
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> 
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev



Back to the top