[dev] WebDAV package v0.1

[Jan Schneider]

Zitat von Evert Pot <evertpot at gmail.com>:

>
>>> 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..
>>
>> Yes, the latter.
>>
>>> 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?
>>
>> We use the browse method not only for WebDAV access, but also  
>> internally, to browse from one application to objects of a  
>> different application. Since this feature resembles the same  
>> directory-like tree like we use in WebDAV/CalDAV, we should share  
>> the code. I don't stick to using a single browse() method, and I'm  
>> also fine with requiring Sabre for people that want CalDAV support,  
>> but whatever we chose for browsing the application resources should  
>> work without any dependency on external code. Hope this makes  
>> things clearer.
>
> It does make things clearer, however.. I don't think I'm up for the  
> task to build this api. If you are looking to build something that  
> provides tree-like access to the various horde components, well..  
> this is sort of out of the scope of what I'm trying to do.

Of course, and this is not what I would ask from you.

> Would it be an option if I can just focus on the parts that are more  
> relevant to me? For me this would just be webdav and caldav protocol  
> support. The resulting code _should_ be simple, so if there are  
> future plans to map this to a unified backend, this should be doable.

Sure, and this is all I am asking for. What I want is to find a  
solution for CalDAV and Sabre integration, that we could later re-use  
internally. I don't want duplicate code for CalDAV any other browse  
APIs.
It's not your job to do this for the other APIs, but the design around  
CalDAV should be done so that we could re-use it as some later point.  
Having a dependency on Sabre is road-block for any such attempt in the  
future. That's why I would prefer if Sabre would not be as strict as  
using interfaces, but simply expecting (and documenting) a certain API  
instead.

> By no means I'm trying to quickly whip something up and offload it  
> for you guys to maintain, but I would like to stay within the scope  
> of creating a simple layer that connects SabreDAV to Horde's  
> controllers. I don't plan to make any changes in existing RPC  
> methods. It sounds like they are already in use for other purposes,  
> so perhaps this will even be an opportunity to remove some of the  
> webdavisms from that code, such as obscure properties that only make  
> sense for people with a fairly intimate knowledge of the  
> specifications.
>
> Effectively I'm proposing separating WebDAV integration from  
> everything else, for the benefit of simplicity.

Again, this would lead to code duplication, because the differences  
between what we need for internal browsing and WebDAV/CalDAV are  
smaller than the similarities. You don't have to care about our  
internal browsing at the moment, but we do. So if you are proposing a  
new layout that makes implementing CalDAV easier, and if we are happy  
with this layout, all I'm asking is that you tweak it, so that we can  
use it anywhere else too.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/