- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 09 May 2013 18:15:31 -0400
- To: public-ldp-wg@w3.org
- Message-ID: <518C2003.1070004@openlinksw.com>
On 5/9/13 5:46 PM, Ashok Malhotra wrote: > > On 5/9/2013 3:03 PM, Wilde, Erik wrote: >> - one popular opinion is that if you look at transactions for your REST >> service, you have a design-level granularity problem. this means that if >> you want to create a scope that extents beyond a single interaction, >> then >> your interaction granularity is too small, and you should design >> representations that represent that bigger scope, so that you can handle >> everything in just one interaction. (in the popular shopping example, >> this >> translates to the client handling all shopping cart contents as >> application state, and then submitting the complete shopping cart >> contents >> in one request when checking out.) > I don't think you can do that, in general, for LDP. For example, you > could update the assets > and the liabilities collections and the server could go down after it > updated the assets but before > it updated the liabilities leaving the data in an inconsistent state. > > I think you are saying that you do all updates on the client and then > send to server as a single > bundle. Yes, that would work but I don't know how to bundle a bunch > of PUTs, POSTs and > DELETEs into a single interaction. > > I agree that this can get messy with distributed transactions etc. but > we need some sort of ACID > guarantee. What should we do? Leave it to the LDP compliant server to handle, since this is seriously out of scope for LDP :-) Kingsley > > Ashok > > > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 9 May 2013 22:15:54 UTC