Re: (un)blessed container use cases and implementation expectations

Ted,

On 5 Nov 2012, at 17:44, Ted Thibodeau Jr wrote:
> But why
> should we declare that all LDP containers are analogous to 
> filesystem directories?

1. You don't have to use LDP containers in your implementation. The only thing that LDP containers give you is that they can assign new URIs by POSTing to the container. If your application doesn't need that, then it won't use containers, and all you have is a simple stupid graph where none of the container complexities matter.

2. Servers can refuse requests to delete containers for any reason, right? “There's something in the container” seems like a perfectly fine reason to me.

The baseline to me is that a server may refuse to delete a non-empty container. In that case, clients may try to delete them one by one.

But if a server allows deleting a non-empty container, and deletes all its members along with the container, that should also be conforming. The nice thing is that the same clients would still work, and no extra machinery is needed in the protocol. It's simply an implementation decision on the server side -- is the implementer willing to go the extra mile or not?

I'd say that a server that deletes a container but lets its members lie around is not conforming. That way, a client would never know if the members were deleted or not, and *has* to check them all individually.

> If I burn a box ("delete" it) that holds a bunch of marbles, the 
> marbles still exist (and start rolling around the floor)

An odd choice of metaphor! If I throw the box in the trash ("delete" it), then the marbles are in the trash too. But it would be quite reasonable for the housekeeper to say: “Don't throw away that box! It has marbles in it!”

Best,
Richard



> -- and
> this may be the right way to handle things, as, for instance, in
> the case of a filesystem with Hard Links -- where there are many
> pointers to the same "physical" resource, where the resource should
> not be dropped, even if one of the pointers thereto should.
> 
> Now, we *could* say that we want to make the simple filesystem case 
> easier, and there are many ways we might do that -- by creating 
> a specific "composed-container"-type; or a "composition" container 
> property (aggregate vs composed or some such); or a property for 
> the contained objects that basically says "delete me when my 
> container is deleted"; or various others.
> 
> I'm fine with (probably) any of these -- and incline toward having
> more options than fewer -- but I want to be quite sure that we don't 
> declare that any existing (known or unknown) implementation that 
> otherwise conforms to LDP, is suddenly non-conformant (thereby 
> offending and disenchanting an early implementer) because the 
> deletion of a container there does not automatically delete the 
> resources it contains.
> 
> My bottom line -- the manual behavior should be the basis of our
> specification.  Easing/automating some special cases is certainly
> reasonable -- but these automated/eased cases should not then 
> become our baseline of compliance.
> 
> Be seeing you,
> 
> Ted
> 
> 
> 
> --
> A: Yes.                      http://www.guckes.net/faq/attribution.html
> | Q: Are you sure?
> | | A: Because it reverses the logical flow of conversation.
> | | | Q: Why is top posting frowned upon?
> 
> Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
> Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
>                             //              http://twitter.com/TallTed
> OpenLink Software, Inc.      //              http://www.openlinksw.com/
>         10 Burlington Mall Road, Suite 265, Burlington MA 01803
>     Weblog   -- http://www.openlinksw.com/blogs/
>     LinkedIn -- http://www.linkedin.com/company/openlink-software/
>     Twitter  -- http://twitter.com/OpenLink
>     Google+  -- http://plus.google.com/100570109519069333827/
>     Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
> 
> 
> 
> 
> 
> 
>

Received on Monday, 5 November 2012 19:55:16 UTC