[
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