Hi Greg!
> 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"...
I'd say that this is totally on-topic for our list.
> 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.
That's what I was thinking. I need the DAV-space "backend" anyway before
this would do anything useful.
> 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.
Of course. Why didn't I think of this (coffee is brewing, I'll get better,
promise!)
> 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
I think the .html discriminator would work better (for us):
/DAV/topic/<id>.html
/DAV/topic/<id>/<id>.html
But this is semantics, they're in essence the same.
I don't see this as a real issue, but just needed it summarized for the
IRC meeting.
> 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.
Right. I don't think we'll enable DAV in the runtime area now, anyway,
until we have the backend done right and a good concept for mining
sourcelinks and other properties.
> In the Midgard sense, I presume? For WebDAV, they are equal.
Yes.
> 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.
Interesting. I haven't heard her name before. Is there info on this?
> I believe the API design is pretty independent from that of a filesystem.
>
> 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).
This is what I meant by "like a filesystem" (vs an allocation scheme as
Midgard uses).
Working around it is going to be tricky. Any idea how long it would
take for these concepts to crystallize (and find their way into the
mod_dav api)?
> 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?
For the moment, strictly the DAV area.
> 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.
We'll keep you posted.
Thanks for the input,
Emile
--
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]
