Hi Emile, (and Midgard people! :-)
Good to hear from you. I was thinking about emailing you, as mod_dav
0.9.13 just went out this weekend.
I'll try to respond to some of your points below. I am also unsure about a
few points, which I'll ask about. I apologize in advance if this is an
intrusion on the Midgard mailing list... I'm not familiar with its
"topical limits"...
On Tue, 23 Nov 1999 [EMAIL PROTECTED] wrote:
>...
> Since all midgard-served pages will consist of many elements (topics,
> articles, style elements, page records), I was planning to use the
> source-link feature of WebDAV to point into a reserved URL region
> on a Midgard server (the DAV space) where resources would be
> represented in their barest form.
>
> I've met some challenges here in that it isn't know what resources
> will be used for a page until the page is called up by HTTP, so
> the page will need to "explain" what resources it uses. This is
> doable (although not trivial) for single pages, harder for DAV requests
> that issue a Depth: infinity header.
>
> I've temporarily let that just sit there while I was thinking about
> the DAV space. It looked simple enough, but there's going to be
> some interesting challenges here too.
Yes, this is a very difficult problem. For simple, dynamic resources that
have a well-defined source (such as a PHP script), the DAV:source property
works really well. When you try to include all the various inputs, then it
gets complicated (as you found :-).
It may be worthwhile to skip the DAV:source property for now, and expect
the author to know where in the DAV tree they want to go. If they want to
edit a style, then they go to the collection of styles (rather than using
DAV:source to automatically direct them there).
Note that there are no sophisticated DAV-aware authoring tools. Yes, some
know about DAV, but none of them really deal with DAV properties, let
alone the DAV:source property. Some of the issues related to dynamic
resources have actually been discussed in the past few days on the DAV
Working Group mailing list (i.e. where to go, what to do, beyond the
DAV:source property). Given a bit of time, some of the problems may become
clearer and can be applied to Midgard.
Given time constraints: you can safely skip DAV:source since you won't see
any user-authoring-tool benefit from it for quite a while.
> I had the following concept for the DAV space:
>
> /DAV/person (collection that holds all person records)
> /DAV/group/<gid> (collection that holds person records for group gid)
> ...
> /DAV/host/<id>/root
> /DAV/host/<id>/style
> ...
> /DAV/article/<id>
> /DAV/topic/direct/<id>
> /DAV/topic/<id>/<id>/<id>/...
> /DAV/topic/<id>/<id>/<id>/<article>
> ...
>
> Something like symlinks would be useful (for things like linking root pages/
> styles from a host tree to their corresponding page/style/etc tree) but
> I can't find anything on that in the DAV spec. Maybe the source link is
> good for this.
I believe Midgard would be creating a custom provider for mod_dav. Since
this would be sucking data directly from your databases, a "symlink"
wouldn't really apply. You would be able to simply return the same data
(from the db) via a couple URIs.
> Anyway, for the real challenges: objects in the DAV space can be both
> collections ("directories") and members ("files"). DAV dictates that
> resources be either one, but not both. The new advanced collections
> specification will probably address this, but mod_dav doesn't implement
> it at the moment.
Advanced collections won't change this. A resource can only be one thing.
As we (Emile and I) have discussed before, this could be an issue for
Midgard. Given a resource such as /a/b, WebDAV makes no distinction based
on whether it is expressed as /a/b or /a/b/. Its view is "resource b in
collection a; b may be another collection, or a member." The terminating
slash is a SHOULD requirement for collections, but it does not alter what
resource b actually is.
Within the Midgard DAV namespace (your /DAV/ area), you could have two
resources corresponding to each form of the Midgard object. For example,
let's say you could have:
/DAV/whatever/collections/abc
/DAV/wahtever/members/abc
This could present "abc" as a collection in one area and as a file in
another. Note that this is just for authoring purposes. In the "runtime"
Midgard area, you could continue your auto-selection based on the
Request-URI.
> Then there's the issue that not all members and collections are equal.
In the Midgard sense, I presume? For WebDAV, they are equal.
> Unlike in the filesystem, you can't move a member of the article
> collection to a style collection. Issueing a 'NOT ALLOWED' response
> for these situations probably solves that.
Yes, this would be quite legal. Any MOVE/COPY can be denied (because of
incorrect permissions, locks, whatever; in your case, because of improper
semantics).
I'm not familiar with the Midgard structure, and how you might structure a
DAV namespace to represent that, but it certainly wouldn't be
inconceivable to completely rule out any MOVE/COPY within the namespace.
> Both these are solveable, but there's a bigger challenge up ahead.
>
> mod_dav will allow one to plug in a repository of your choice (filesystem,
> database, desk clerk) but expects that repository to pretty much behave
> as a filesystem.
Well... this isn't quite true. John Vasta at Rational Software has written
a provider for mod_dav that lets it work against Rational's ClearCase
product. In this mode of operation, mod_dav does not hit the filesystem at
all, and it deals with a very abstract notion of what a "resource" is.
Fran Taylor has implemented a provider that delivers all provider API
requests through a CORBA layer to remote objects. They want their
webserver outside their firewall and to use mod_dav/CORBA to go thru the
firewall to grab content.
Your provider can map a Request-URI to your own underlying concept. If
mod_dav needs to do any traversal (this is one of two things: go "up"
in the namespace, or to "walk" the namespace below the resource), then it
asks the repository to assist it.
I believe the API design is pretty independent from that of a filesystem.
> You can tell a WebDAV enabled server to create a member
> 'index.html' at URI '/user/emile', but that's not how Midgard works,
> where you request a new object at URI '/user/emile' and get handed it's
> ID in return.
Hrm. This just came up on the DAV Working Group list about a month or so
ago. There were some suggestions for how to handle this. I don't recall
them right now :-( I seem to recall something about returning a Location:
header from a PUT or a MKCOL to indicate where the thing was actually
created/stored. Another suggestions was to create a "binding" between the
URI that the author used and the "true" URI (the ID-based one).
But yes... this would be an issue. Also note that a question arises here:
would the author attempt to create the index.html in the "runtime" area,
or would they know to go to the /DAV/ area?
> This will be a major problem for DAV clients who expect to treat a DAV
> server as a NFSish service (to wit, IExplorer and office 2000), and I
> see no provisions in the DAV spec that would allow creation of
> resources in the Midgard way.
This is true. We'd need to review that thread on the WG list to see if
there was a clean solution.
> DAV will probably be one of the topics of the IRC meet thursday, so
> if you have any thoughts on this you're very welcome to join, or send
> reactions to the list of course.
I've never used IRC... give me a MUD or email :-) I would be more than
happy to review an IRC log and answer any DAV questions that may arise.
And certainly, my mailbox is always open before/after your IRC meet.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
