Re: [Planner] gnome-vfs (WebDAV) support?

[Bryan Cole <bryan cole teraview com>]

On Thu, 2005-08-04 at 18:21 -0400, Kurt Maute wrote:
> On Tue, 2005-08-02 at 10:14 +0100, Bryan Cole wrote:
> > Can Planner use gnome-vfs for rw-access to WebDAV shares? It doesn't
> > work out-the-box with my binary version, but I could rebuild from source
> > if gnome-vfs can be enabled.
> 
> Not that I know of, though it would be a cool feature if someone were
> inclined to add it.

One worry is that (after googling on Planner and gnome-vfs) is that a
previous gnome-vfs build dependence was recently removed from planner
(presumably in the name of portability). 

WebDAV could be added directly using the neon library. If planner had
more complete/documented python bindings (I couldn't get the python-demo
example to work on my 0.13 version) I'd volunteer for this task as a
python-plugin project.

> 
> I'm copying the developer list on this - maybe we can get more
> discussion on that list.

Great. I've been following the planner lists on GMane, but
'gmane.comp.gnome.apps.planner.user' does not appear to correspond to
this list. Can anyone explain? Where can I join the developer list? The
information on both (imendio and other) planner sites is ambiguous.

> Sounds like a cool idea.  The reservation I have about implementing
> something like this is that once you have all Planner files in a
> database, people will want to pose queries against it for reporting
> purposes, and those are not likely to be looking for 'diffs' between one
> project version and the next, but more likely to be across the project
> portfolio - in which case you'd have to pull each project xml and do
> some fairly complex coding to get anything of value.

Well I'm also a fan of DB backends. However, a full featured SQL backend
is rather complex to design (and would also be easier done as a python
plug-in to take advantage of all the high-level python DB modules).

WebDAV support is simply a matter of saving/loading the existing file
format to a new URL type.

I disagree that manipulating the planner XML is complex. The beauty of
XML is the ease with which you can parse the file and extract the
information you need. However, for more sophisticated analysis of the
planner data, e.g. dependency or resource tracking, SQL doesn't really
help you (I think writing a pure SQL query to calculate the length of a
project based on the dependencies of all subtasks would be ... a
challenge!). In this case, the best place to do this type of analysis is
within planner itself (i.e. the planner application is always the best
client for working with planner data). The way forward would be to
expand the script interface to planner's functionality to allow custom
export etc. WebDAV provides the network transparency / groupware aspect.
The revision control is just a fringe benefit of webdav.

XML, being good for tree type document data has advantages of it's own.
Chopping and changing the branches of the xml-tree is easy to do. E.g.
exporting a task (with sub-tasks) as a new project or combining multiple
projects into a "master project" is easy with XML.

The advantage of a SQL backend is all the existing client tools:
querying and exporting to e.g. Open/MS-Office is easy for report
generation. With a XML solution (even the XML-DB you suggest, which does
look very very cool) would require extra scripting to get the data into
report form.

> 
> Prepare your overripe produce for launching in my direction now, 'cause
> here comes the radical idea. 

My seatbelt is fastened.

>  How about using a Native XML Database
> instead?  The idea behind these is that you stuff entire XML documents
> into them and they do some technomagic to organize the data into trees
> so it becomes much quicker to access than groups of flat files.  
> 
> In fact, maybe we should look at using NXDs rather than PostgreSQL &
> MySQL as well?  Certainly I'm no expert, but it seems they offer
> flexibility to both the user who wants to query them and the developer
> who doesn't want to get into a major upgrade struggle every time he
> wants to add or change a data element in the xml heirarchy.
> 
> Here's a good article:  http://xml.sys-con.com/read/90126_1.htm
> It uses Berkeley DB XML (open source) as its example NXD database, and
> its very readable for the not-so-technical.

Yup, an excellent idea indeed. Seems like a great way to add a query
interface without breaking the xml data-model.


Bryan