472,141 Members | 1,373 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,141 software developers and data experts.

WebDAV Server

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?
--
Jody Winston

Jul 18 '05 #1
4 2868
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.

--
René Pijlman
Jul 18 '05 #2
Rene Pijlman <re********************@my.address.is.invalid> writes:
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.


We had to roll our own data store since we deal with terabytes of
data.
Of course, Zope has a WebDAV server, but I don't know if
using Zope is overkill.


Perhaps you can use ZServer standalone.


Thanks, I'll take a look at ZServer.
--
Jody Winston
Jul 18 '05 #3
[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,

--
alan kennedy
------------------------------------------------------
email alan: http://xhaus.com/contact/alan
Jul 18 '05 #4
Alan Kennedy <al****@hotmail.com> writes:
[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.
Jul 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Glenn Holliday | last post: by
reply views Thread by SimpleSimple | last post: by
7 posts views Thread by Steve Drake | last post: by
reply views Thread by Alex Radice | last post: by
1 post views Thread by =?Utf-8?B?QWxleCBSYWtvdg==?= | last post: by
reply views Thread by arjen1984 | last post: by
reply views Thread by alexander.stuckenholz | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.