Re: ISSUE-36: Summary of ways of making containers

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. 

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?

> 
>> 
>>> 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/