You're almost completly correct, but the "member's ancestor's" does not mean
all descendant members ;)

 For example take a collection like this one:

 - ole
   + toro
   - chica
        - Buena.txt
      - Gostosa.txt

 You intend to delete the 'ole' collection but, the ole/chica/Gostosa.txt
file is locked by another user. The resulting request should return a
multistatus message saying that:

 ole/toro collection and all it's descendants were deleted;
 ole/chica/Buena.txt file was deleted;
 ole/chica/Gostosa.rxr file failed to be deleted;
 ole/chica collection failed to be deleted;
 ole collection failed to be deleted.

 As you can see, all 'ole/chica/Gostosa.txt' ANCESTORS were NOT deleted "so
as to maintain namespace consistency" :)

 Hope this helps,
 Miguel

____


Hello all,

 thank you guys for your answers. I think i understand
your reasoning, however i would refer again to the
rfc2518 section 8.6.2 where it states "If any resource
identified by a member URI cannot be deleted then all
of the member's ancestors MUST
NOT be deleted, so as to maintain namespace
consistency". For me this means that the server will
execute the delete operation only if it has access to
all the resources wich needs to be deleted.

I tested with the slide server, and it behaves as it
is   descrebed in the spec.

In my view in this case the 207 status code, clearly
indicates a failure.

Please correct me if i am wrong.




--- Ingo Brunberg <[EMAIL PROTECTED]> wrote:

> This is the same problem as with a PROPPATCH with
> multiple
> properties. The methods in WebdavResource simplify
> things too much in
> returning only a boolean value for these methods
> that can be partially
> successful. Returning false would not be the right
> thing either.
> 
> If you have a good idea how to tackle that problem,
> let us know.
> 
> Ingo
> 
> > Hi,
> > 
> > can somebody please, clarify the following issue
> with
> > the WebdavResource.deleteMethod(String) in the
> client
> > library?
> >  
> > If i want to delete a collection wich is not
> empty,
> > according to the rfc2518 section 8.6.2 "If an
> error
> > occurs with a resource other than the resource
> > identified in the Request-URI then the
> > response MUST be a 207 (Multi-Status).", and
> indeed
> > this is happening, but the problem is that the
> client
> > doesn't get notified about the failure of the
> delete
> > operation because in the deleteMethod(String) the
> > "return (statusCode >= 200 && statusCode < 300) ?
> true
> > : false;" is used and the 207 statusCode also will
> > return true.
> > 
> > Is this a bug, or it is my missunderstanding? 
> > Thank you.
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



                
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to