search

solid / solid-spec

Solid specification draft 0.7.0
Creative Commons Zero v1.0 Universal
1.13k stars 103 forks source link

PUT for create requires extension of LDP #30

Open bblfish opened 9 years ago

bblfish commented 9 years ago

In the section HTTP PUT to create the following is written.

Another useful feature that is not yet part of LDP deals with using HTTP PUT to create new resources. This feature is really useful when the clients wants to make sure it has absolute control over the URI namespace -- e.g. migrating from one pod to another. Although this feature is defined in HTTP1.1 RFC2616, we decided to improve it slightly by having servers create the full path to the resource, if it didn't exist before.

Currently it is not clear how a client would ever know that a server implemented this feature without out-of-band information. Because LDP Containers are not Intuitive Containers, a client has no guarantee that when doing a PUT in a namespace it is even allowed to do so in that part of the name space. Furthermore it has no way of knowing in a standard way that the intermediate directories will be created.

I don't see this listed on the LDP Next Charter, though there is still time to add this feature there if it is felt to be useful enough.

deiu commented 9 years ago

Yes, this is a non-standard improvement to PUT that we could propose as an extension to LDP. It is currently described (specced) in this doc so that people writing apps for SoLiD can speed things up a bit.

In any case, a client can still create the container hierarchy if it is unaware that PUT also creates parent containers.

bblfish commented 9 years ago

Yes, this is a non-standard improvement to PUT that we could propose as an extension to LDP

It would help then if it were part of the LDP Next Charter. If you don't put it there it won't even be considered.

In any case, a client can still create the container hierarchy if it is unaware that PUT also creates parent containers.

Why would a client bother trying to do something when there is a chance in 10 or 100 that it will work correctly? Unless the client can know that this will work, there is no reason to guess. Otherwise the client will have to have code such as if (origin=="rww.io" | origin = "data.fm" | .... ) { ... } else { .. } and that code would need to be changed every time a new server came up hosting this extension.

deiu commented 9 years ago

I see your point. I think we can address it in LDP Next, where we plan to have a way for servers to advertise what they support.

bblfish commented 9 years ago

Well the easy way to do that is to specify sublcassses of ldp:Container such as the iContainer I proposed. But it still would help to have wider agreement of the meaning, and have a w3c namespace, so you need to get it explicitly in the charter.

deiu commented 9 years ago

Getting things into the charter is not that easy. It requires group agreement, so the best I (or you) can do is to suggest it to the group during the next call.

bblfish commented 9 years ago

well in any case, one cannot specify this behavior without indicating that it is available. So one needs to create a subclass of ldp:Container - such as iContainer mentioned in issue 50

http://www.w3.org/2012/ldp/track/issues/50

(but one could extend it, for the more general behavior required here) so that it is clear to clients what they can expect.