WebDAV and other questions...

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?  
Obviously common implementations use file systems to represent/store
these resources.  The relevance of this question will become apparent
below..  :-)

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

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

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


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?


Sorry for the length of the post.

Thanks,

Mike