Re: We need to step up to database functionality

hello all.

john already answered this, and it all comes down to that in REST, the
resource model decided everything. if you model resources in a way that
require you to lock some and interact with all of them and then release
the lock, then most likely you have chosen a resource granularity that is
not a good fit for the interaction patterns you want to support. i wrote
about this a little while ago:

http://dret.typepad.com/dretblog/2009/05/rest-and-rdf-granularity.html

the main point is that even when you have an RDF model of something, you
still haven't answered the hypermedia questions about the services on top
of that: what are the interaction patterns you support, and on which "RDF
documents"? that's critical for REST.

On 2013-11-03, 16:58 , "Ashok Malhotra" <ashok.malhotra@oracle.com> wrote:
>    But I want to touch on a broader issue.  With LDP we allow multiple
>    users access to a web resource,
>    and some of these users may be able to update the resource or some
>    part of it.  This takes us into
>    database territory but we have steadfastly chosen to ignore
>    functionality like
>    - access control
>    - transactions
>    - locking    
>    We need to consider these because it will come back and bite us in
>    the butt when, for example, users' updates are partially reflected
>(transactions).

john's claim and mine as well is that access control is out of scope (and
i think we said so explicitly earlier on), while transactions and locking
should be relegated to an appropriate resource granularity model. if an
LDP server has problems with transactions/locking, then it probably has
been set up in a way which exposes a resource model that's not a good
choice. instead of changing LDP, the server then should change its
resource model, so that interactions are actually stateless.

cheers,

dret.

Received on Monday, 4 November 2013 17:12:20 UTC