Jeen suggested to put the server-side logic into the server-side repository code, if I understood his mail right.

Leo would rather implement a server on top of the repository (aka the existing Repository Servlet) and then write an independent Sail implementation for the client.

Transactions can be buffered on the client until commited, and then commited in one move (caching) or continously forwarded to a server side transaction ("live").

I wonder if it is already clear how "select" queries will work during a transaction - do they already reflect uncommited changes? that would be complicated. Is there a description of these things?

summing up discussion from mailinglist:
Jeen: The idea here is that the Repository is client-side
and that a client-side Sail implementation, the HTTP Sail, takes care of
handling remote transactions, communicating through the SPARQL++
protocol with a remote Sesame repository. So that is in fact very
similar to what you had in mind - the HTTPSail acts as a proxy for the
remote store, and on the client we can treat it as any other repository.

The problem I was alluding to above is that this client-side HTTP Sail
will receive a Query object, and will need to serialize that in some
fashion to send it over HTTP to the remote repository. Two ways to serialize:

1) Serialization via Query-String and taking the original query
string, but the Sail currently does not have access to that. So we can
implement this in two ways: we either reconstruct the query string from
the Query object (a trivial way is that we store the original string in
the object during its creation)

2) Communication already on the repository level. We 'move up' the communication of
queries, to the level where the query string is still known, i.e., the
Repository level. Con: this would break the Sail/repository contract

Jeen: To be honest I am somewhat in favor of the first option myself, even
though it means there will be an unnecessary parse of the query - it
seems the least intrusive in the 'normal' operation of things.

Leo: version 1) is better, the hack of passing the query string within the query is ok.