Were there meeting notes posted as a result of this phone call?
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 3/14/07 11:33 AM >>> 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
_______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
|