- From: Alexandre Bertails <bertails@w3.org>
- Date: Wed, 23 Jan 2013 10:43:07 -0500
- To: Henry Story <henry.story@bblfish.net>
- CC: Steve Speicher <sspeiche@gmail.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
On 01/23/2013 10:33 AM, Henry Story wrote: > > On 23 Jan 2013, at 16:20, Alexandre Bertails <bertails@w3.org> wrote: > >> On 01/23/2013 10:00 AM, Steve Speicher wrote: >>> On Wed, Jan 23, 2013 at 4:41 AM, Henry Story <henry.story@bblfish.net> wrote: >>>> In summary here are the proposed ways of allowing applications to make >>>> containers: >>>> >>>> 1. Using the MKCOL HTTP Method from WebDAV >>>> ------------------------------------------ >>>> >>>> - Works like GET/PUT/POST/DELETE . >>>> - Implemented in 100s of millions of clients on MS-Windows, OSX, Linux, and other Unixes for WebDAV >>>> - RFC: http://tools.ietf.org/html/rfc4918#section-9.3 >>>> >>> >>> Seeing the value in this. If we want to tunneling the MKCOL through >>> POST we could do that as well, something like X-HTTP-Method-Override: >>> MKCOL. >>> >>> Note: we could do something similar for PATCH. >> >> Sadly, some http clients in old browsers won't let you add custom >> headers either. We may have to consider the URL hack as a fall-back >> (this is a common problem in the web apis world). > > I think what you call the URL hack may be what solution 3 - the container > factory - is about. So in that case the container factory answer, could be > something suggested in a seperate document as a workaround for dealing > with problematic old browsers. Of course you're right! But there are two different things here: 1. specifying the normal scenario with for example MKCOL 2. specifying a degraded mode to handle the case of clients that cannot comply with the spec So we need to do both. > But seriously, any applications using this api that is going to > be working in the browser is going to be working in a browser that is > using javascript, and using it a lot! It is only recently with the huge > speed improvements in JS brought to modern browsers that such apps are > even conceivable. So are old browsers really that relevant? Because we're dealing with some W3C guys here, yes "old" browsers are relevant :-) On a more serious note, the fact that this is a problem for many of the web apis out there is a good indicator that we cannot safely ignore it here. Alexandre. > >> >>> >>>> 2. POST + server looks at content of graph >>>> ------------------------------------------ >>>> >>>> if graph posted to ldp:Container </satellite/x4354/> contains the triple >>>> >>>> <> a ldp:Container . >>>> >>>> the server makes a container. >>>> >>> >>> Makes sense. Of course, client could add some non-member triples as >>> this point as well. >> >> These "non-member triples" could also be part of the request-body of >> the MKCOL. This is actually much more important than it looks at first >> sight. For example, Andrei and I have a use-case where we need to add >> other triples to "configure" the container. >> >> I can live with either 1.+fallback or 2., but I have a slight >> preference for 1.+fallback as it makes the operation very clear, and >> we can make decisions before looking at the body. >> >>> >>>> 3. Link from LDPC to factory >>>> ---------------------------- >>>> >>>> The container </satellite/y500/> contains a link to a factory <makeAnotherContainer> . >>>> >>>> <> a ldp:Container; >>>> ldp:containerFactory <makeAnotherContainer> . >>>> >>>> <makeAnotherContainer> would then be something else besides an LDPR or an LDPC. >>>> It would need to describe itself as a factory and tell you for which collection it was a >>>> factory for. One can then POST something into the <makeAnotherContainer> factory in >>>> order to create a collection inside the original </satellite/y500/> . >>>> >>> >>> I guess I don't fully understand why adding this overhead helps. >>> >>> This seems to set us up to need a "Factory" predicate for any kind of >>> thing that can be created. Perhaps we could instead say way kind of >>> thing can be created in this container. >>> >>> For example, >>> >>> <> a ldp:Container; >>> ldp:canCreate ldp:Container, oslc:ChangeRequest . >>> >>> Then one could look up these Classes to see what they look like. This >>> may be something better for LDP 2.0 (for lack of better name). I have >>> a need for something like this anyway, knowing what kinds of things >>> the container accepts. Disclaimer, the name ldp:canCreate is nothing >>> I'm emotionally attached to. >>> >>>> 4. Link from LDPC to home document that links to factory >>>> -------------------------------------------------------- >>>> >>>> The container contains a link to the home document >>>> >>>> <> a ldp:Container; >>>> ldp:homeDocument <http://nasa.gov/satellite/y500/homeSweetHome/> . >>>> >>>> The home document contains a link to the containerFactory >>>> >>>> <http://nasa.gov/satellite/y500/homeSweetHome/> a ldp:HomeDocument; >>>> ldp:containerFactory <makeContainersFor> . >>>> >>>> Sending a POST to the containerFactory can create a container, but requires >>>> telling the container factory which container one wishes to create the container >>>> in. The containerFactory needs to describe also which containers it can create >>>> a factory for. >>>> >>> >>> I'm not sure why the home document is needed or anything special. >>> Isn't it just a ldp:Container ? Couldn't another application >>> somewhere create a ldp:Container which then includes the first ? >> >> +1 to your 2 previous comments. I don't see any added value in 3. and >> 4., it's just more complicated for both the server and the client. >> >> Alexandre. >> >>> >>>> Henry >>>> >>>> Social Web Architect >>>> http://bblfish.net/ >>>> >>> >>> Thanks for putting this out there, really helps move the discussion >>> along with such good proposals. >>> >>> -- >>> - Steve >>> >>> >> > > Social Web Architect > http://bblfish.net/ >
Received on Wednesday, 23 January 2013 15:43:15 UTC