[dev] WebDAV package v0.1

[Jan Schneider]

Zitat von Jan Schneider <jan at horde.org>:

> 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.

Thinking more about this under the shower today, I think the solution  
that fits both our needs is to use proxy classes. Not the most  
beautiful solution, but as elegant as I can find.

So basically we would have Directory and File classes that implement  
the *API* that SabreDAV needs. We could use these classes for our own  
purposes without having a dependency on SabreDAV.
Then, we would have Directory and File proxy classes that implement  
the SabreDAV *interfaces*, but simply route all the methods to the  
Horde classes.

This way you can stick to requiring the connectors to implement your  
interfaces, and we can still use our implementations without the  
SabreDAV dependency. Does this work for everybody?

Jan.

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