Re: WebDAV and other questions...

Mike Severa schrieb:
> 
> 
> Hi I hope this isnt too basic for this reflector but I had a few 
> questions about webdav and some of its offspring efforts...
> 
> 
> * Web dav *
> 
> * Webdav concepts vs underlying implementations on a webdav server *
> It seems to me that webdav defines a set of concepts.  These don’t get 
> much into how a server must actually implement them… ie I can do a get 
> on some "resource" but, the physical representation of that resource 
> could be a file, it could be some field(s) in a database, it could be 
> squirrel generating random sequences using the rate of his running 
> wheel…as long as the interface to the resource followed the rules of 
> webdav and associated specfications.  Would you say this is a fair 
> statement?  (I guess a resource would be something able to be defined in 
> an http entity body so perhaps the squirrel example is not that 
> appropriate.)  If not, does webdav (or http) make an assumption about 
> the underlying implementation? 

No, you got that absolutely right. As a matter of fact, Roy Fielding 
(author of HTTP spec) keeps pointing out that an HTTP URI can identify 
*anything*, such as a robot  :-)

> Obviously common implementations use file systems to represent/store 
> these resources.  The relevance of this question will become apparent 
> below..  :-)

...or databases...

> * Mkcol *
> if im not mistaken this command is part of the original webdav rfc.  The 
> concept seems to be to specify a "collection".  As always, 
> implementation is a good indicator of behavior, and apache uses this to 
> acually create a directory.   In think the closest the webdav rfc comes 
> to talking about implementation in this case is
> 
> " Collections: The ability to create sets of documents and to retrieve a 
> hierarchical membership listing (like a directory listing in a file 
> system)."
> 
> But that is the only time the term "directory" is even used in that 
> rfc.  It seems to me that this is probably sufficient for standard 
> wedav-style usage, ie creating a "collection" and adding physical 
> entities to it… ie mkcol = mkdir, put = cp (from webdav client), where 
> after some sequence of these commands you might end up with a directory 
> structure with a bunch of physical files in it.
> 
> I think this makes sense until I saw the bind additions… 
> 
> 
> * Bind *
> 
> * Status *
> My first question about bind is the status of this from the standpoint 
> of approval and implementation.  Its not clear from the ietf db when 
> bind will be considered for approval, though the current text expires in 
> a few days. 

It has been through several Last Calls with no issues left, but it is 
currently blocked by the fact that RFC2518bis doesn't make any progress, 
to which it has a normative reference.

> In addition, apache includes hooks for the bind (and even the search… 
> more about that below) mechanism(s), though it doesn’t appear to 
> actually provide an implementation of proper handling.  Do you have any 
> idea what the status of that is?  I would understand if they are holding 
> off on implemntation until the rfc is approved… I would ask the apache 
> group, but my guess is the bind implementation would probably be done by 
> someone in the webdav group would probably know more about that status 
> than an apache person might.


No, I don't know anything about ongoing implementation work in Apache.

It *is* implemented in the server I've been working on (SAP KM), and it 
may surface in Jackrabbit once the equivalent of BIND is added to the 
JCR API (Java Content Repository).

> * Implementation *
> My second question relating to bind is about how its (or will be) 
> actually implemented, if that’s relevant.  Since my tests on apache 
> appear to imply its not implemented, it is unclear what will happen when 
> I use the bind mechanism.  In some sense, as mkcol is similar to mkdir, 
> where it creates a physical file system entity (directory), I could see 
> bind being something equivalent to a file system symbolic link.  Just as 
> bind allows a resource name to point to another resource on the system, 
> symbolic links allow the same thing from a file system standpoint. 

It's more similar to an Hard Link. The filesystem equivalent of a 
symbolic link is an HTTP redirect Reference (RFC4316).

> While this would make sense, I think it could pose some problems.  
> Firstly, I think bind is extremely useful and I could envision scenarios 
> where the number of bindings would be several (or even more) orders of 
> magnitude in number larger than the number of physical resources.  If 
> that becomes true, this could mean a significant performance hit for 
> using bind in a very large, webdav-based system.  While symbolic links 
> of course take much less space than the physical resource, in a system 
> where such things as properties also exist--which may take zero physical 
> file system resources, rather stored in some kind of database (which may 
> of course in turn rely on the file system)--I would question whether the 
> implementer would want to use the file system as the preferred mechanism 
> for implementing the bind, even if it were only a symbolic link.
> 
> So… if in fact the bind would be implemented in some other fashion, eg 
> database, there would be some kind of inconsistency bewteen the mkcol 
> and bind behavior from an implementation standpoint.  Ie it would be 
> possible to look at the file system on which the server is based and 
> actually see all the directories created by mkcol, but they could all be 
> empty while still having bindings that could be retrieved via webdav.  I 
> don’t think this would techincally be illegal with in the context of 
> webdav, but could pose some problems for assumptions made about 
> implementations elsewhere, including in apache…

Right. It's always tricky to use both FS and database in sync. We do 
that in some SAP KM "repository managers" (== storage backends), but 
it's better to avoid that.

> Although as I mentioned above I think the rfcs have tried to stay away 
> from implementation details, I think the usefulness of somethink like 
> bind could make implementation an important factor, especially if the 
> standard paradigm becomes unusable because of complexity issues.  I do 
> undersatnd that apache is a plug-in model, so in reality, anyone could 
> implement it how they want.. But apache also usually provides default 
> implementations of methods and being that it has something like 75% 
> market penetraton as a web server, I think its probably a relevant 
> question.
> 
> Sorry if that is a bit abstract...

I think BIND can be implemented using hard links. However, I'm not sure 
whether APR (the Apache Portable Runtime) supports that.

> * Search (dasl) *
> 
> * Status *
> 
> I am very interested in this functionality as well.  I notieced from the 
> webdav.org page there are some comments that it was trashed by ietf but 
> that Julian was still spearheading it.  However the last update to that 
> page seems to be around 2004.  what is the status of this?  I noticed a 
> hook for it has also been provided in apache… is that fact meaningful?

It's kind of stuck. A long time ago we thought that XML Schema and XPath 
2.0 would give us a foundation to steal from, but you're probably aware 
of the slow progress over there.

I may be able to get back to it when over things are done (such as BIND, 
RFC2518bis...). My latest version always can be found over here: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html>.

> Sorry for the length of the post.
> 
> Thanks,
> 
> Mike

No problem. Hope my answers were helpful for you.

Best regards, Julian

Received on Thursday, 24 August 2006 22:17:17 UTC