Skip to content
This repository has been archived by the owner on Apr 13, 2022. It is now read-only.

PUT for create requires extension of LDP #30

Open
bblfish opened this issue Jun 15, 2015 · 6 comments
Open

PUT for create requires extension of LDP #30

bblfish opened this issue Jun 15, 2015 · 6 comments

Comments

@bblfish
Copy link
Contributor

bblfish commented Jun 15, 2015

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
Copy link
Contributor

deiu commented Jun 15, 2015

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
Copy link
Contributor Author

bblfish commented Jun 15, 2015

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
Copy link
Contributor

deiu commented Jun 15, 2015

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
Copy link
Contributor Author

bblfish commented Jun 15, 2015

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
Copy link
Contributor

deiu commented Jun 15, 2015

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
Copy link
Contributor Author

bblfish commented Jun 15, 2015

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants