Re: [xdi] Evented API spec

[Drummond Reed <drummond.reed@xdi.org>]

Bill,

This is an extremely well-worded critique, and I agree with every point you make. I wish you were going to be at IIW to make these points in person to Phil and Sam. I will do my best to try to bring them up with them and see what they answer.

Just to clarify, I did tell them that I saw the XDI inner circle inside the Evented API outer circle being 100% XDI, i.e., it didn't actually need the Evented API. What you're saying is that outside the XDI circle, the Evented API doesn't add enough value to compete with other options that already exist outside the XDI circle.

I think that's a very valid point, and again one I'll bring up with them.

Our focus is of course what can be done inside the XDI circle, and your point about XDI being perfect for EBI makes me feel even more strongly that the XDI circle is getting wider every day.

=Drummond

On Thu, Oct 13, 2011 at 4:00 AM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:

Hi Drummond,

This is a beautifully written spec and a very nice job -- but in my opinion unnecessary for XDI.

I've been pushing async XDI for over two years now and the only thing required to enable a msg is to specify an XDI endpoint the result goes to. We've had several mechanisms for that proposed on the TC.  Async XDI gets you about 50% of the way, without tying XDI into an external spec specific to the HTTP transport. Async XDI being when you send a message and specify that any outgoing message not be sent back to the message sender but be sent to another XDI endpoint.

Link contracts are data sharing contracts, and that's what pub/sub is about.  Link contracts are an ideal way to handle pub/sub, which with async XDI gets you to 80%.

For the other 20%, an event is nothing more than a data interchange that specifies a state change has occurred and an XDI message is a data interchange that by the nature of XDI signals a state change in the global graph.  Want to trigger processing based on an XDI message? That would be supported by a link contract.

Personally I think in XDI we have a much better technology for Event Based Integration (EBI, and the original term for this, see Fielding's http://roy.gbiv.com/untangled/2008/economies-of-scale)  

 

The Evented API is great for people that are tied to HTTP, though why they can't use Atom Publishing Protocol, OStatus, WebSockets, or one of the other protocols that do similar things I don't know.  For everyone else I'd suggest pushing XDI rather than Evented API, and trying to convince Phil Windley and Sam Curren of the EBI power inherent in XDI.

Kind regards,

 

Bill Barnhill

---

From: xdi@lists.oasis-open.org [xdi@lists.oasis-open.org] on behalf of Drummond Reed [drummond.reed@xdi.org]
Sent: Thursday, October 13, 2011 1:46 AM
To: OASIS - XDI TC
Cc: Phillip J. Windley Ph.D.; Sam Curren
Subject: [xdi] Evented API spec

I wanted to bring to everyone's attention the Evented API independently published last week by Phil Windley and Sam Curren of Kynetx. Phil's blog post about it is at:

  http://www.windley.com/archives/2011/10/the_event_api.shtml

The spec itself is at:

  http://www.eventedapi.org/

I gave Phil and Sam some early comments on it, but my two primary takeaways were:

1. This is a very simple and elegant way to achieve interop on events on a very wide scale.
2. It is a perfect fit for XDI.

The picture I shared with them was one of concentric circles: the outer circle would be all systems that supported the Evented API, the inner circle would be all systems that supported it and for which the Evented API endpoints were also XDI endpoints.

In the latter case, all the semantics of the messages, event subscriptions, authentication, authorization, etc. would already be built in. What we've been calling an XDI network would be an evented XDI network.

Phil and Sam are going to hold sessions on this at Internet Identity Workshop next week so we'll be able to discuss further there, but please do look over the spec and share any thoughts you have in advance of that. I'll put in on the agenda for a brief discussion on tomorrow's call as well.

=Drummond