[dev] WebDAV package v0.1

[Evert Pot]

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