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” with the “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
sip: =les/(+phone)
chat: =les/skype/chat