Stephen This looks like a great document, I'll try to address as many of your questions as I feel able to and add some thoughts of my own in places
Section 2 I like the idea of using a custom header, it avoids cluttering the query string or the form body Section 3 May we worth having an OPTIONS request on the /transaction endpoint allowing users to look up supported options - transaction types, timeout, isolation etc Section 4 May be worth returning the entity regardless because this avoids an extra trip for people who want the other transaction info like type, start time etc I would suggest allowing for a timeout parameter but allowing servers to ignore or override it, effective timeout should be included in transaction info. On isolation level it may be worth permitting configurable levels, individual stores can choose to only provide those they support and indicate which they support in response to OPTIONS requests Section 5 May want to add extra info like effective timeout, whether a transaction is eligible for commit or not Sections 7 & 8 Note sure 410 Gone is the right status for failure since it is a client error and a commit/rollback failure is most likely to be a server error. Therefore I would be tempted to use a 500 Internal Server Error if the action fails because the server can't carry it out Of course for user errors such as trying to commit a transaction that is no longer eligible for commit e.g. already committed, rolled back, errored etc then you would use an appropriate user error like 409 Conflict. And other standard statuses would apply such as 404 Not Found for invalid transaction IDs Appendix A Punting on security seems the best solution to keep the spec lightweight, individual implementors can implement whatever security mechanisms they want for authentication and authorisation and SSL can be used to protect from MITM attacks. May be worth noting that auth is left to implementations and assumes standard HTTP Auth mechanisms are used. Hope this feedback is helpful, Rob On 19/05/2014 21:22, "Stephen Allen" <[email protected]> wrote: >All, > >I've been working on a design for remote transactions for SPARQL >(initially >for the query and update endpoints, but most likely for GSP as well). My >initial draft is at [1]. I would appreciate any feedback, particularly in >the places where I have made notes (the @@ sections). > >Although I tried to design it to not preclude distributed transactions, I >am intentionally limiting the specification to what is necessary for a >single server currently. > >Implementation seems like it should be fairly straightforward, targeting >Fuseki 2 / TDB. There look to be a few bumps that need to be overcome >(particularly TDB's usage of ThreadLocal variables >in DatasetGraphTransaction), but there do not appear to be any >showstoppers. Although I have not started writing any code yet. > >I have started JENA-700 to track this work [2]. > >-Stephen > >[1] http://people.apache.org/~sallen/sparql11-transaction/ >[2] https://issues.apache.org/jira/browse/JENA-700
