Fwd: Coming up to speed on XDI

---------- 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.

xdi message