WebDAV package v0.1

[Evert Pot-2]

Here's the package for horde-git:





I also made a preliminarily dav.php (end of this email).

Some notes:
   * Still needs lots of docblocks
   * Needs more testing
   * Only forwards GET, PUT, DELETE, PROPFIND, MKCOL to respective  
applications.

Since this is only intended as a compatibility layer, I'm not  
implementing the advanced features, such as custom properties.

I want to add a dedicated Web/SabreDAV interface to Kronolith,  
replacing the existing methods from the RPC system.
One suggestion is to add a new method to to Kronolith_API, called  
something like getWebDAVTree, or add a new file called Kronolith_DAV,  
which is automatically discovered(not sure how that would work within  
horde??)

All this effort is to reduce WebDAV-logic from respective  
Kronolith_API classes, and more into the protocol layer. Currently I  
see a lot of duplication of validation and little application-level  
controllers, which can all be simplified.

Feedback is highly appreciated :)

<?php
/**
  * WebDAV endpoint
  *
  * This script triggers Horde's WebDAV server.
  *
  * $Horde: horde/rpc.php,v 1.58 2009-08-03 17:04:29 jan Exp $
  *
  * Copyright 2002-2009 The Horde Project (http://www.horde.org/)
  *
  * See the enclosed file COPYING for license information (LGPL). If you
  * did not receive this file, see http://www.fsf.org/copyleft/ 
lgpl.html.
  *
  * @author Jan Schneider <jan@...>
  */

require_once dirname(__FILE__) . '/lib/core.php';

$input = null;
$params = array();

/* Load base libraries. */
$horde_authentication = 'none';
require_once HORDE_BASE . '/lib/base.php';

/* Start the server */
$server = new Horde_DAV_Server();
$server->exec();

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Chuck Hagenbuch]

Quoting Evert Pot <evertpot@...>:

> Here's the package for horde-git

I haven't looked at this more closely yet because I don't want to  
tread on the kronolith/caldav project which I haven't been directly  
involved in. However if you, Jan, etc. want me to take a closer pass  
at it please let me know.

A few general comments though:

> I want to add a dedicated Web/SabreDAV interface to Kronolith,  
> replacing the existing methods from the RPC system. One suggestion  
> is to add a new method to to Kronolith_API, called something like  
> getWebDAVTree, or add a new file called Kronolith_DAV, which is  
> automatically discovered(not sure how that would work within horde??)

What do you mean by replacing the existing methods? The existing  
webdav code? Or the API methods themselves?

We have autoloading; what would Kronolith_DAV need to be discovered  
by? I guess I'm not following the overall shape of your suggestion.

> All this effort is to reduce WebDAV-logic from respective  
> Kronolith_API classes, and more into the protocol layer. Currently I  
> see a lot of duplication of validation and little application-level  
> controllers, which can all be simplified.

I'm all for getting more of the application logic into a controller  
structure, making validation and such reusable. Ideally from my  
perspective this would be done for all of Kronolith, not just the DAV  
part.

-chuck

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Jan Schneider]

Hi Evert,

Zitat von Evert Pot <evertpot@...>:

> Here's the package for horde-git:

Two packaging related issues:
- When installing the tarball with pear, I get a: ERROR: file  
/tmp/pear/download/DAV/DAV-0.0.1/lib/Horde/DAV/ApplicationCollection.php does  
not exist. Funnily, it's the ApplicationFile.php script though, that's  
not correctly linked in the <phprelease> section of package.xml
- Since this is the Horde wrapper of the Sabre_DAV package, you should  
rather make it a patch against the framework/Sabre library that  
already exists in the horde-git repository.

To the code:
- There are a few coding style issues, but that's not important for  
now. The only thing that you should change is camel-case'ing the class  
names, so that it's easier to patch the code right from the start,  
when it's integrated into Horde. I.e. Horde_Dav, not Horde_DAV.
- Overall looks pretty nice and slim. I guess it's a good sign for  
Sabre's and Horde's APIs that the wrapper can be kept so small.

More remarks:
- The HTML interface is really cool! I didn't even know it existed.
- Browsing individual calendars don't work. The calendars come up  
empty. The address book works fine.
- There seems to be some infinite loop browsing task lists. But that's  
probably inside Nag.

Regarding a separate interface to Kronolith:
If this is necessary and makes sense, I'm for adding a separate class  
that could be auto-detected with autoloading, like Chuck suggested.
But I would first like to hear more details which WebDAV logic you  
consider overhead, that could be saved with a separate interface.  
Regarding controllers, what Chuck said.

Jan.

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


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Evert Pot-2]

On 2009-10-19, at 3:35 PM, Jan Schneider wrote:

> Hi Evert,
>
> Zitat von Evert Pot <evertpot@...>:
>
>> Here's the package for horde-git:
>
> Two packaging related issues:
> - When installing the tarball with pear, I get a: ERROR: file /tmp/
> pear/download/DAV/DAV-0.0.1/lib/Horde/DAV/ApplicationCollection.php  
> does not exist. Funnily, it's the ApplicationFile.php script though,  
> that's not correctly linked in the <phprelease> section of package.xml

Not sure how that happened, but this should be an easy fix.

> - Since this is the Horde wrapper of the Sabre_DAV package, you  
> should rather make it a patch against the framework/Sabre library  
> that already exists in the horde-git repository.

I figured a the Horde_Dav package would be more appropriate than  
'Sabre_DAV', hence the rename. I can supply this as a real patch  
though (just need to figure out git a bit more).
>
> To the code:
> - There are a few coding style issues, but that's not important for  
> now. The only thing that you should change is camel-case'ing the  
> class names, so that it's easier to patch the code right from the  
> start, when it's integrated into Horde. I.e. Horde_Dav, not Horde_DAV.

No problem making it Dav. Is there a specific standards guide I can  
follow, or do you guys use the Pear 1 coding standards?

> - Overall looks pretty nice and slim. I guess it's a good sign for  
> Sabre's and Horde's APIs that the wrapper can be kept so small.

Thanks!



--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Evert Pot-2]

Sorry for the late responses, I was on a trip for a week with very  
little internet access.

>> I want to add a dedicated Web/SabreDAV interface to Kronolith,  
>> replacing the existing methods from the RPC system. One suggestion  
>> is to add a new method to to Kronolith_API, called something like  
>> getWebDAVTree, or add a new file called Kronolith_DAV, which is  
>> automatically discovered(not sure how that would work within horde??)
>
> What do you mean by replacing the existing methods? The existing  
> webdav code? Or the API methods themselves?
>
> We have autoloading; what would Kronolith_DAV need to be discovered  
> by? I guess I'm not following the overall shape of your suggestion.

This is a brief overview of how the webdav system works right now:

The top level directory is a listing of all horde applications. Only  
horde applications that have the 'browse' rpc method are added to this  
list.
This RPC class has a number of methods, such as get, put, path_delete  
and mkcol that all take a path argument, and internally handle the API  
method based on the path.

All these methods in every API class (Kronolith_Api, Nag_Api, etc..)  
will have to maintain some sort of translation of this path to an  
internal controller. The datasource of a 'browse' on a list of users,  
will have to originate from a very different subsystem than for  
example a list of calendar objects, or directory tree in Gollem.


How SabreDAV was designed is very different, it could definitely be  
argued there are cons to this approach, but I do feel it helps keeping  
things simpler.
Simply put SabreDAV has three node classes:

Node
File (extends Node)
Directory (extends Node)

The File class adds methods such as 'get' and 'put, and the Directory  
class adds methods such as 'getChildren' and 'createFile'.
The biggest difference is that there is no central API class that  
handles all HTTP methods for various paths, but every single file or  
directory is represented by 1 object.

The implication is that the Dav api's for every Horde application will  
likely consist of a couple of classes, every class representing a  
different type of object within horde (1 for a file in gollem, 1 for a  
directory in gollem, 1 for a list of kronolith users, and so on..).  
This will result in more classes, but smaller chunks of simple  
functionality.

One way to approach this, is for example a class such as this:

class Kronolith_Dav {

   function getRootNode() {

     return new Kronolith_Dav_UserList();

   }

}

Here are some stubs of classes that would appear within Kronolith:

class Kronolith_Dav_UserList extends Sabre_DAV_Directory {

   function getChildren() {

     // logic for listing all the users

   }

   function getChild($name) {

     // logic for returning a single users' object.

   }

   function getName() {

     // the path name that will be used in the webdav directory  
structure.
     return 'kronolith';

   }

}

class Kronolith_Dav_User extends Sabre_DAV_Directory {

   function getChildren() {

     // logic for listing all a users calendars

   }

   function getName() {

     // This is probably a username
     return 'chuck';

   }

   function createCalendar($name) {

     // Creates a new calendar with the supplied filename.

   }

}

And another one:

class Kronolith_Dav_CalendarObject extends Sabre_DAV_File {

   function get() {

      // returns the current iCalendar object

   }

   function put() {

      // updates the current iCalendar object

   }

}

Does this make sense at all? I'm not sure if I'm explaining this well..

Evert


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Evert Pot-2]

Missed your last notes:

On 2009-10-19, at 3:35 PM, Jan Schneider wrote:
>
> More remarks:
> - The HTML interface is really cool! I didn't even know it existed.

It's a very simple interface, but I felt it's a bit more intuitive for  
people to use. It would be pretty easy to make one specific to horde  
as well.

> - Browsing individual calendars don't work. The calendars come up  
> empty. The address book works fine.

I'll check this out..

> - There seems to be some infinite loop browsing task lists. But  
> that's probably inside Nag.

I haven't tested the code yet with Nag, just a few other  
applications.. But I'll also have a look at this, in case it does have  
to do with my code.

> Regarding a separate interface to Kronolith:
> If this is necessary and makes sense, I'm for adding a separate  
> class that could be auto-detected with autoloading, like Chuck  
> suggested.
> But I would first like to hear more details which WebDAV logic you  
> consider overhead, that could be saved with a separate interface.  
> Regarding controllers, what Chuck said.

Some notes about this in my email back to chuck.

Thanks for having a look,
Evert

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Michael M Slusarz-2]

Quoting Evert Pot <evertpot@...>:

> All these methods in every API class (Kronolith_Api, Nag_Api, etc..)  
> will have to maintain some sort of translation of this path to an  
> internal controller. The datasource of a 'browse' on a list of  
> users, will have to originate from a very different subsystem than  
> for example a list of calendar objects, or directory tree in Gollem.

This code is probably better off living in the *_Application classes.  
*_Application is meant for methods that are defined in the Horde  
Framework that might exist in individual applications (you can almost  
think of them as hooks for applications).  *_Api is meant for unique,  
application specific methods that are entirely defined within that  
application.

michael

--
___________________________________
Michael Slusarz [slusarz@...]


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Jan Schneider]

Zitat von Evert Pot <evertpot@...>:

> On 2009-10-19, at 3:35 PM, Jan Schneider wrote:
>
>> Hi Evert,
>>
>> Zitat von Evert Pot <evertpot@...>:
>>
>>> Here's the package for horde-git:
>>
>> Two packaging related issues:
>> - When installing the tarball with pear, I get a: ERROR: file  
>> /tmp/pear/download/DAV/DAV-0.0.1/lib/Horde/DAV/ApplicationCollection.php  
>> does not exist. Funnily, it's the ApplicationFile.php script  
>> though, that's not correctly linked in the <phprelease> section of  
>> package.xml
>
> Not sure how that happened, but this should be an easy fix.
>
>> - Since this is the Horde wrapper of the Sabre_DAV package, you  
>> should rather make it a patch against the framework/Sabre library  
>> that already exists in the horde-git repository.
>
> I figured a the Horde_Dav package would be more appropriate than  
> 'Sabre_DAV', hence the rename. I can supply this as a real patch  
> though (just need to figure out git a bit more).

That's fine for me too. As I mentioned earlier, I'm not set on  
Horde_Dav vs. Sabre_Dav anyway.

>> To the code:
>> - There are a few coding style issues, but that's not important for  
>> now. The only thing that you should change is camel-case'ing the  
>> class names, so that it's easier to patch the code right from the  
>> start, when it's integrated into Horde. I.e. Horde_Dav, not  
>> Horde_DAV.
>
> No problem making it Dav. Is there a specific standards guide I can  
> follow, or do you guys use the Pear 1 coding standards?

http://cvs.horde.org/co.php/horde/docs/CODING_STANDARDS

Jan.

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


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Jan Schneider]

Zitat von Evert Pot <evertpot@...>:

> Sorry for the late responses, I was on a trip for a week with very  
> little internet access.
>
>>> I want to add a dedicated Web/SabreDAV interface to Kronolith,  
>>> replacing the existing methods from the RPC system. One suggestion  
>>> is to add a new method to to Kronolith_API, called something like  
>>> getWebDAVTree, or add a new file called Kronolith_DAV, which is  
>>> automatically discovered(not sure how that would work within  
>>> horde??)
>>
>> What do you mean by replacing the existing methods? The existing  
>> webdav code? Or the API methods themselves?
>>
>> We have autoloading; what would Kronolith_DAV need to be discovered  
>> by? I guess I'm not following the overall shape of your suggestion.
>
> This is a brief overview of how the webdav system works right now:
>
> The top level directory is a listing of all horde applications. Only  
> horde applications that have the 'browse' rpc method are added to  
> this list.
> This RPC class has a number of methods, such as get, put,  
> path_delete and mkcol that all take a path argument, and internally  
> handle the API method based on the path.
>
> All these methods in every API class (Kronolith_Api, Nag_Api, etc..)  
> will have to maintain some sort of translation of this path to an  
> internal controller. The datasource of a 'browse' on a list of  
> users, will have to originate from a very different subsystem than  
> for example a list of calendar objects, or directory tree in Gollem.
>
>
> How SabreDAV was designed is very different, it could definitely be  
> argued there are cons to this approach, but I do feel it helps  
> keeping things simpler.
> Simply put SabreDAV has three node classes:
>
> Node
> File (extends Node)
> Directory (extends Node)
>
> The File class adds methods such as 'get' and 'put, and the  
> Directory class adds methods such as 'getChildren' and 'createFile'.
> The biggest difference is that there is no central API class that  
> handles all HTTP methods for various paths, but every single file or  
> directory is represented by 1 object.
>
> The implication is that the Dav api's for every Horde application  
> will likely consist of a couple of classes, every class representing  
> a different type of object within horde (1 for a file in gollem, 1  
> for a directory in gollem, 1 for a list of kronolith users, and so  
> on..). This will result in more classes, but smaller chunks of  
> simple functionality.
>
> One way to approach this, is for example a class such as this:
>
> class Kronolith_Dav {
>
>   function getRootNode() {
>
>     return new Kronolith_Dav_UserList();
>
>   }
>
> }
>
> Here are some stubs of classes that would appear within Kronolith:
>
> class Kronolith_Dav_UserList extends Sabre_DAV_Directory {
>
>   function getChildren() {
>
>     // logic for listing all the users
>
>   }
>
>   function getChild($name) {
>
>     // logic for returning a single users' object.
>
>   }
>
>   function getName() {
>
>     // the path name that will be used in the webdav directory structure.
>     return 'kronolith';
>
>   }
>
> }
>
> class Kronolith_Dav_User extends Sabre_DAV_Directory {
>
>   function getChildren() {
>
>     // logic for listing all a users calendars
>
>   }
>
>   function getName() {
>
>     // This is probably a username
>     return 'chuck';
>
>   }
>
>   function createCalendar($name) {
>
>     // Creates a new calendar with the supplied filename.
>
>   }
>
> }
>
> And another one:
>
> class Kronolith_Dav_CalendarObject extends Sabre_DAV_File {
>
>   function get() {
>
>      // returns the current iCalendar object
>
>   }
>
>   function put() {
>
>      // updates the current iCalendar object
>
>   }
>
> }
>
> Does this make sense at all? I'm not sure if I'm explaining this well..

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?

Jan.

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


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Evert Pot-2]

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


 

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Evert Pot-2]

On 2009-10-22, at 7:01 PM, Michael M Slusarz wrote:

> Quoting Evert Pot <evertpot@...>:
>
>> All these methods in every API class (Kronolith_Api, Nag_Api,  
>> etc..) will have to maintain some sort of translation of this path  
>> to an internal controller. The datasource of a 'browse' on a list  
>> of users, will have to originate from a very different subsystem  
>> than for example a list of calendar objects, or directory tree in  
>> Gollem.
>
> This code is probably better off living in the *_Application  
> classes.  *_Application is meant for methods that are defined in the  
> Horde Framework that might exist in individual applications (you can  
> almost think of them as hooks for applications).  *_Api is meant for  
> unique, application specific methods that are entirely defined  
> within that application.

That sounds good to me.


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Evert Pot-2]

>>
>> No problem making it Dav. Is there a specific standards guide I can  
>> follow, or do you guys use the Pear 1 coding standards?
>
> http://cvs.horde.org/co.php/horde/docs/CODING_STANDARDS
>

Thanks sir

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Jan Schneider]

Zitat von Evert Pot <evertpot@...>:

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

Jan.

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


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Evert Pot-2]

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

> Zitat von Evert Pot <evertpot@...>:
>
>>> [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

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Jan Schneider]

Zitat von Evert Pot <evertpot@...>:

>
> On 2009-10-22, at 7:41 PM, Jan Schneider wrote:
>
>> Zitat von Evert Pot <evertpot@...>:
>>
>>>> [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..

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.

Jan.

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


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Evert Pot-2]

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

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.

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.

Evert

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Jan Schneider]

Zitat von Evert Pot <evertpot@...>:

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


--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Chuck Hagenbuch]

Quoting Evert Pot <evertpot@...>:

> No problem making it Dav. Is there a specific standards guide I can  
> follow, or do you guys use the Pear 1 coding standards?

horde/docs/CODING_STANDARDS (out of CVS still) is mostly up to date,  
except it doesn't have the specific rules for the PHP 5 packages. For  
that, unfortunately the only real reference is the packages that are  
already in git.

-chuck

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Chuck Hagenbuch]

Quoting Evert Pot <evertpot@...>:

> Sorry for the late responses, I was on a trip for a week with very  
> little internet access.
>
>>> I want to add a dedicated Web/SabreDAV interface to Kronolith,  
>>> replacing the existing methods from the RPC system. One suggestion  
>>> is to add a new method to to Kronolith_API, called something like  
>>> getWebDAVTree, or add a new file called Kronolith_DAV, which is  
>>> automatically discovered(not sure how that would work within  
>>> horde??)
>>
>> What do you mean by replacing the existing methods? The existing  
>> webdav code? Or the API methods themselves?
>>
>> We have autoloading; what would Kronolith_DAV need to be discovered  
>> by? I guess I'm not following the overall shape of your suggestion.
>
> This is a brief overview of how the webdav system works right now:
>
> The top level directory is a listing of all horde applications. Only  
> horde applications that have the 'browse' rpc method are added to  
> this list.
> This RPC class has a number of methods, such as get, put,  
> path_delete and mkcol that all take a path argument, and internally  
> handle the API method based on the path.
>
> All these methods in every API class (Kronolith_Api, Nag_Api, etc..)  
> will have to maintain some sort of translation of this path to an  
> internal controller. The datasource of a 'browse' on a list of  
> users, will have to originate from a very different subsystem than  
> for example a list of calendar objects, or directory tree in Gollem.
>
>
> How SabreDAV was designed is very different, it could definitely be  
> argued there are cons to this approach, but I do feel it helps  
> keeping things simpler.
> Simply put SabreDAV has three node classes:
>
> Node
> File (extends Node)
> Directory (extends Node)
>
> The File class adds methods such as 'get' and 'put, and the  
> Directory class adds methods such as 'getChildren' and 'createFile'.
> The biggest difference is that there is no central API class that  
> handles all HTTP methods for various paths, but every single file or  
> directory is represented by 1 object.
>
> The implication is that the Dav api's for every Horde application  
> will likely consist of a couple of classes, every class representing  
> a different type of object within horde (1 for a file in gollem, 1  
> for a directory in gollem, 1 for a list of kronolith users, and so  
> on..). This will result in more classes, but smaller chunks of  
> simple functionality.

[snip]

> Does this make sense at all? I'm not sure if I'm explaining this well..

Yes, this sounds good and I agree with the general approach. I  
wouldn't take the current Horde API classes as gospel too much -  
they're to a pretty old API at this point, and if I were to do it over  
again I'd split things up a lot more. This is an opportunity to do  
that, at least in part.

-chuck

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...

[Chuck Hagenbuch]

Quoting Evert Pot <evertpot@...>:

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

I'm pretty sure Jan already responded here in the affirmative, but  
yes, that's fine. We can collaborate on the overall work that's  
necessary.

-chuck

--
Horde developers mailing list - Join the hunt: http://horde.org/bounties/
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: dev-unsubscribe@...