WebDAV Server

[Jody Winston]

I'd like to present a view of an internal data store, which has Python
interface built using SWIG, so that my users can traverse and
manipulate the data store using familiar tools. My first thought was
to adapt an existing WebDAV server. However, I cannot seem to find a
simple way to do this. davserver-0.5.1 by Christian Scholz doesn't
work with 4Suite 1.0a3 and I couldn't find an implementation for
twisted. Of course, Zope has a WebDAV server, but I don't know if
using Zope is overkill.

Should I continue down this path and if I do, should I write a WebDAV
server for twisted or bite the bullet and use Zope?

 

[Rene Pijlman]

Jody Winston:

I'd like to present a view of an internal data store, which has Python
interface built using SWIG, so that my users can traverse and
manipulate the data store using familiar tools. My first thought was
to adapt an existing WebDAV server.

If the data store was ZODB, you would have described Zope.

Of course, Zope has a WebDAV server, but I don't know if
using Zope is overkill.

Perhaps you can use ZServer standalone.

 

[Jody Winston]

Jody Winston:

If the data store was ZODB, you would have described Zope.

We had to roll our own data store since we deal with terabytes of
data.

Perhaps you can use ZServer standalone.

Thanks, I'll take a look at ZServer.

 

[Alan Kennedy]

[Jody Winston]

I'd like to present a view of an internal data store, which has Python
interface built using SWIG, so that my users can traverse and
manipulate the data store using familiar tools.

Have you considered using something like pythonfs: "Linux Filesystem
Drivers for backends written in Python"?

http://pythonfs.sourceforge.net/

Your backend could be your swig-wrapped internal data store. Then your
users could use familiar file management tools on your data store.

It could be exposed to a web server as the document root of the server:
which would be nice because you could pick any standard webserver and
not require it to be in python: every webserver understands filesystems.

Same argument applies to webdav, i.e. you could use a native webdav
module for, say, Apache, layered over your data-store "filesystem".

[Jody Winston]

My first thought was
to adapt an existing WebDAV server.

I'm not sure that adapting someone elses webdav component would be the
most appropriate solution. Most such modules will likely apply their own
semantics to webdav methods and properties, which are relevant only to
their own intended storage mechanism. Take, for example, the subversion
module for apache, which has webdav support. But it performs all webdav
operations directly on the contents of a subversion repository, which
has versioning, branching, labelling semantics, etc.

If you just wanted a read-only view of your data store, I would suggest
using a web framework such as quixote to map uris to your
(hierarchical?) data store somehow. Quixote is structured around the
concept of mapping uris to python objects in a straightforward and
configurable manner, so it might be a good fit. You could then extend
the model to support PUT, POST, HEAD, OPTIONS, etc, methods as well. By
which time you would have implemented a significant proportion of WEBDAV

Which leads onto the question: what operations do you intend to
facilitate on your data store? What kinds of tools do you wish to allow
people to use to access it, and what kinds of operations should those
tools support?

For instance, if your data is more relational than hierarchical, it
might be more appropriate to write an ODBC front-end for your datastore?

regards,

 

[Jody Winston]

[Jody Winston]

I'd like to present a view of an internal data store, which has Python
interface built using SWIG, so that my users can traverse and
manipulate the data store using familiar tools.

Have you considered using something like pythonfs: "Linux Filesystem
Drivers for backends written in Python"?

http://pythonfs.sourceforge.net/

Your backend could be your swig-wrapped internal data store. Then your
users could use familiar file management tools on your data store.

The problem that I have with kernel level modules such as fuse is that
I must keep it in sync with the kernel on lots of machines.
(http://www.top500.org/sublist/System.php?id=7058) Life becomes much
easier if I stay only in userspace.

It could be exposed to a web server as the document root of the
server: which would be nice because you could pick any standard
webserver and not require it to be in python: every webserver
understands filesystems.

Same argument applies to webdav, i.e. you could use a native webdav
module for, say, Apache, layered over your data-store "filesystem".

Adding a module to Apache does allow me to stay in userspace.
However, I have not ever written a module for Apache.