Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core]

On Tue, Mar 19, 2013 at 3:13 PM, Wilde, Erik <Erik.Wilde@emc.com> wrote:
> hello steve.
>
> On 2013-03-19 7:51 , "Steve Speicher" <sspeiche@gmail.com> wrote:
>>This is not in line with what I was proposing, a regular-DELETE would
>>remove just the container (both the triples of members and
>>non-members).  In the case of recursive-DELETE, it would do the same
>>as regular-DELETE and issue a recursive-DELETE on each container
>>member object URL.
>
> if it works this way, aren't you intentionally orphaning all members and
> they will become undiscoverable once you have DELETEd the container around
> them? while this is not violating REST, it is not a very useful pattern,
> because it means that all these resources essentially become "Zombies in
> RESTland" once you have deleted the container.
>
> cheers,
>
> dret.
>

One thing I'm not hearing is feedback on part a), is this an
improvement or not?  Or are you saying, until we have a clear
direction for b) then you can answer a)?

You might be orphaning but why is that a big problem?  The client
knows it is doing this by knowing what DELETE does, if it cares about
the links it should keep a reference to them or not do the DELETE.  A
server could run some cleanup tasks to remove orphan resources, if it
thinks it is a problem, or place them in some server-managed special
container say called "orphans" (application-specific behavior).  I
would not refer to them as orphans or zombies, it is quite possible
that an external application is holding a reference to that member
resource and therefore it is not orphaned in the web sense...just the
managing server doesn't have a client requested container to leave it
in.

--
- Steve Speicher

Received on Wednesday, 20 March 2013 12:35:11 UTC