W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: Creation of Containers

From: Richard Cyganiak <richard@cyganiak.de>
Date: Wed, 7 Nov 2012 23:01:44 +0000
Cc: public-ldp-wg@w3.org
Message-Id: <44A0F260-F299-494A-A1C7-367FAB937740@cyganiak.de>
To: Niclas Hoyer <niclas@verbugt.de>
On 7 Nov 2012, at 22:45, Niclas Hoyer wrote:
>> A question though: Can't you solve it by having a sioc:Forum that is an ldp:Container that creates threads?
> 
> I think this just displaces the problem, because a client program maybe wants to create a new sioc:Forum and that needs to be created somehow.

Have you heard of sioc:Site? ;-)

>> The very first container on the site perhaps has to be initialized by the server administrator when setting up the LDP server. Then, everything else can be created through that container. It's a bit like in a filesystem; the root already has to exist for you to be able to create new files or directories.
> 
> That is exactly what I understand by a "general" implementation. For example one could setup such a resource for a group like the ldp working group. This resource could then be turned into a container. If we e.g. want to add mailinglist functionality, one could create a new subresource, turn that into a container which is also a sioc:Forum and start messaging.

If the server “knows” what kinds of resources are supposed to be containers (e.g., it starts with one Site container, and then allows the creation of Forum containers within, and then allows the creation of Threads within, and Post within, etc.), then clients can be simple and stupid. They just need to POST to create new resources. The interface between clients and servers is very simple

With your approach, the clients need to be a lot smarter -- they need to know how to turn resources into containers. And they need to do it in exactly the right way for the particular server implementation. The protocol between clients and servers has become a lot more complicated.

It has also become more generic, because the server needs no hardcoded domain knowledge.

It's a trade-off.

I would expect that most servers *want* hardcoded domain knowledge, because they drive a specific application (like a forum, or a bug tracker). And if that assumption is correct, then it means that most clients can be kept simple because the server will already know what resources need to be containers. Hence, the more complex clients that you envision will play in a smaller pool with few servers to talk to, and maybe will never get critical mass. Therefore, I'm sceptical about putting this kind of “client-created container” into the spec.

As always, I may be completely wrong about any of this.

Best,
Richard
Received on Wednesday, 7 November 2012 23:02:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC