Transactional integrity & the XDI protocol (was Re: [xdi] [External] Connection)

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

Joseph, my intuition is that your intuition is right ;-)

Seriously, it keeps coming up that we need enough transaction integrity semantics in the XDI protocol so that clients can unambiguously ask a server to do what the client wants, and servers can unambiguously know how to tell a client what messages/operations worked and what didn't. In other words, accurate, unambiguous communication of state.

Since in XDI every operation request in every message is a state change (even a $get is a state change if it is logged), then maybe we just need to bite the bullet and apply the multiplicity patterns to XDI messaging. The basic rules would be:

1. A single message with a single operation would not need any transaction integrity semantics - the message either succeeds or fails, and the message ID already identifies the message. However the server may need to return the message ID in the response.
2. A single message with a collection of operations would need to order the operations using ordinal statements. The server performs the operations in order. If an operation fails, the whole message fails, and the server sends back the full XDI statement of the operation that failed (because that XDI statement is already unique).
3. A collection of messages (whether with single operations or collections of operations) would need to:
1. Order the messages so the server can perform them in order.
2. Include basic commit/rollback semantics for message collections.

If you agree, then we should put together a formal proposal for this so we can start discussing it.

=Drummond 

On Sat, Jul 7, 2012 at 4:50 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:

On Jul 6, 2012, at 6:53 AM, Barnhill, William [USA] wrote:

I propose that rather than deciding which methods to explicitly support, we instead create a generic authentication mechanism, i.e. something like SASL.  If XDI messaging were a connection-oriented protocol then I would suggest an XDI binding of the SASL abstraction layer.  However, to my knowledge XDI messaging has always been, and is intended to remain, a connectionless protocol (or more precisely a message-oriented protocol).

I strongly feel that it will turn out to be advantageous to maintain connections, and that we should anticipate this. I realize we want to get the simplest case (no connection, minimal HTTP methods/codes, minimal authentication) out the door quickly, but can we give this a little thought now? It may be as simple as numbering messages and responses so that the client knows which response was to which message, or only sending responses in order received. Is it clear where a message ends - do we have a clear end of message marker?