[dev] WebDAV package v0.1

Evert Pot evertpot at gmail.com
Thu Oct 22 18:31:20 UTC 2009


On 2009-10-22, at 7:41 PM, Jan Schneider wrote:

> Zitat von Evert Pot <evertpot at gmail.com>:
>
>>> [snip]
>>> That sounds like a clean approach to me. OTOH we still need  
>>> similar functionality for internal browsing, but it doesn't make  
>>> sense to use objects extending Sabre_DAV classes for that purpose.
>>> Does Sabre require those objects to extend the Sabre classes, or  
>>> is it sufficient to implement a certain object API?
>>
>> You can actually implement the interfaces (Sabre_DAV_INode, IFile,  
>> IDirectory).
>> The classes are there, because all the methods are already  
>> implemented to throw a 'Permission denied' by default, which  
>> results in less code.
>>
>> To find out if an object supports for example directory-like  
>> functinality, just the interfaces are checked. As an alternative I  
>> had been thinking about using duck-typing, but I ended up  
>> preferring interfaces, because it forces developers to be more  
>> strict.
>
> That would still add a dependency on Sabre that I rather don't want  
> for such a core functionality.

Wouldn't a dependency be implied if anyone wants to use webdav  
functionality? Unless you are talking about using the tree for  
functionality beyond webdav..

If the reference in the _Application class is a concern, I'm pretty  
sure everything will work correctly, unless the actual 'getWebDavNode'  
or equivalent method would actually be executed.

Can you help me understand the problem?

Evert


More information about the dev mailing list