RE: [xdi] Persistent connection vs new request per query

Taking a 15 min break to respond (time needs to be kept very separate)…

Regarding suggestion by Markus of WebSockets, I’ve been pushing that for over a year. If you look at the XDI REST proposal I sent earlier today you’ll see the headers and resource URI will work over the life of a WebSocket session involving operations under one address. Rather than a request per XDI operation you’d open a WebSocket connection, negotiate LinkContrat authn/authz, and then exchange XDI messages (one operation per message) until done. This is also how I’ve envisioned XDI notification working.

On the messages from the server, could be done one of two ways:

(1) Have messages from the server be usual XDI GET responses, i.e., XDI data

(2) Have messages from server also be XDI messages designed to operate on client state

I very much prefer (2) because it is more P2P rather than C2S.

I will put the proposals I’ve sent to the list today up on the wiki, in the category CategoryProposals, and do so tonight.

Tomorrow before the meeting please look them over and sign off on the wiki page I create if you have no problems, or comment at the bottom if you have problems with a proposal.

Also, XDI implementation work, i.e., about code or algorithms, can go on planetwork list but I urge everyone to keep spec discussions like this to the OASIS lists. Otherwise the IPR is unclear, which could be a barrier to adoption, and ill-will may be generated amongst OASIS staff and other OASIS members outside the TC, which could be a barrier to ratification.

-B

From: xdi@lists.planetwork.net [mailto:xdi@lists.planetwork.net] On Behalf Of Joseph Boyle
Sent: Thursday, May 24, 2012 2:11 PM
To: xdi@lists.planetwork.net
Subject: Re: [xdi] Persistent connection vs new request per query

Why shouldn't pure-XDI query/result work over any kind of text stream connection? This is the best reason yet to avoid parameters, unless they are not going to change over an entire session.

On May 24, 2012, at 11:06 AM, Markus Sabadello wrote:

Maybe use WebSockets/SPDY.

Markus

On Thu, May 24, 2012 at 7:58 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:

Latency is a good point - the common way to deal with it these days is AJAX or COMET leaving a connection open for data interchange with the server instead of requiring a new request, connection, and response every time. XDI should be prepared to work in this mode and not be hardwired to require a new HTTP request per query.

On May 24, 2012, at 10:16 AM, Markus Sabadello wrote:

Hi all, I thought I'd forward Mark Horstmeier's comments on the REST discussion, and on transactions, which is another subject we may want to discuss at some point :)

Markus

---------- Forwarded message ----------
From: Mark Horstmeier <meh@kynetx.com>
Date: Thu, May 24, 2012 at 6:23 PM
Subject: Re: Coming up to speed on XDI
To: Markus Sabadello <markus.sabadello@xdi.org>
Cc: Phil Windley <pjw@kynetx.com>

If you think that the message would add to the discussion, please do forward it.

I agree with the default being the full message. Breaking it up in transactions is only useful if your ratio of operations to connections is high. (I've noticed that as KRL has made persistent variables easier to access and more useful, our use case changed from solitary connections and monolithic operations to many operations on the data at a fine level of detail, but now latency is my greatest enemy)

Classically, Google uses get, post, put for their API, but they don't try label it as REST. You've seen the noSQL label used to describe a database philosophy, perhaps we need to coin a notSOAP label so we can let people know that the API uses get/post but not enrage the RESTies.

On Thu, May 24, 2012 at 9:03 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

Hello Mark,

Nice to hear from you..

Yes I'm also not fully convinced that a correct and meaningful HTTP REST interface for XDI can be done, but on the other hand Yuriy's latest proposals could work I think..
Craig Burton and Paul Trevithick have been saying for a long time that XDI needs HTTP REST support.
On the other hand, we always used to say that XDI is REST on the XDI layer (the nouns and verbs are XRIs), rather than on the HTTP layer.

The idea of transactions has come up in the past and is important I think.
I think by default each client/server roundtrip should by default be a complete transaction by itself, and unrelated to following roundtrips.

But perhaps we should have special $ words to begin/commit/rollback database-style transactions that can involve multiple roundtrips?

Then within the transaction, a client could send a, b, c, d, e in separate roundtrips.
Or, a client could send a, b, c, d in one roundtrip, and then multiple e statements (the actual operations) in separate roundtrips.
I agree doing this should make it possible to process the link contract only once and therefore optimize the actual operations..

Do you want me to forward your message to the list?
In any case, I'll cc you on further messages..

Markus

On Thu, May 24, 2012 at 12:55 AM, Mark Horstmeier <meh@kynetx.com> wrote:

Markus,

Phil Windley has been forwarding some of the conversations from the XDI group so I can come up to speed on XDI matters.

I had some questions/observations that I sent Phil that probably aren't suited for the mailing list, but we wanted to borrow your expertise.

Looking through the thread on your GET shortcut, it seems to me that mentioning REST probably takes the conversation in a bad direction.

The XDI message is so information rich, adhering to a strict RESTful interface seems too limiting.

However, looking at the sample message, it seems like the individual elements could be implemented in a transactional manner (with tokens for instance)

{from-graph}/$add/{from}$msg{id}
{from}$msg{id}/$is()/{to-graph}
{from}$msg{id}$d/!/(data:,{datestamp})
{from}$msg{id}/$do/{link-contract}
{from}$msg{id}$do/{operation}/{target}

If we regard each of these elements as a separate transaction and label them a-e, I could see each step returning a token, that could then be used RESTfully in the next step.

It seems like I could pre-build the graph so that the eventual operation would be optimized with a sub-graph of only the permissioned elements.

For example. If the link contract request (d) returned a token that I could use for multiple operations (e requests) I could even create a historical record of these virtual sub graphs

This would mean that connections (a-d) are expensive relative to operations (e) assuming that this transactional implementation doesn't violate some XDI convention of which I am not aware.

Another efficiency of this process is coupling message errors/responses more tightly with the generated statements.

These are just thoughts that were triggered by the question of how to fit XDI into a RESTful model. I'm not sure whether this boils down to a implementation option or a protocol error so I would appreciate your thoughts.

____________________________________________________________
You received this message as a subscriber on the list:
xdi@lists.planetwork.net
To be removed from the list, send any message to:
xdi-unsubscribe@lists.planetwork.net

For all list information and functions, see:
http://lists.planetwork.net/lists/info/xdi

____________________________________________________________
You received this message as a subscriber on the list:
    xdi@lists.planetwork.net
To be removed from the list, send any message to:
    xdi-unsubscribe@lists.planetwork.net

For all list information and functions, see:
    http://lists.planetwork.net/lists/info/xdi

xdi message