>>>>> "ian" == Ian Bicking <[EMAIL PROTECTED]> writes:
>> Of course it is, as others have noted. I have several such
>> collections in my main Web app:
>>
>> /images /articles /authors /subjects
ian> But the next level is highly contextualized in a way that is
ian> difficult to generalize over other collections.
Right, that's why I'm suggesting we *not* generalize, out of the box,
for Webware's WebDAV.
/articles/500
ian> is easy enough to parse, but then if you have a heterogeneous
ian> collection /mideast, what does /mideast/500 mean?
If /mideast is a DAV collection, /mideast/500 is a member-uri of that
collection. That's what it means in DAV semantics.
I'm suggest, contrary to what you say at the end, that you can use DAV
to manage collections of *output resources*, despite your saying that
it's not useful to do so. :>
ian> Anyway, 500 isn't a good identifier. /articles/500 is a fine
ian> identifier, but I feel like that will make the hierarchy deeper
ian> than it needs to be.
How so?
That you are referring to an article does
ian> not necessarily mean you have a meaningful collection of
ian> articles which WebDAV can manipulate.
Of course not. But it *may* well be a collection of articles that
WebDAV can manipulate. And it may be so even if there are no
filesystem assets in a docroot matching /articles, and even if every
part of /articles/500 is dynamically generated by doing MySQL
operations. In one case, DELETE /articles/500 means "delete the file
/var/www/my-site/webware/articless/500" and in another case it means
"DELETE row FROM table WHERE condition".
That's what I mean by some parts of DAV can't be generalized over
every application, and so we shouldn't try. At the source resource
level, mod_dav works just fine. We might want to ship a WebDAV
implementation that uses basic filesystem-based content management
system semantics. What I'm also asking for is that it be possible and
practicable to implement other kinds of semantics, too.
>> In short, I find GET /collection/member-uri?query=delete to be
>> completely bonkers, but YMMV. :>
ian> Yes, I agree. Perhaps delete was a bad example -- you get
ian> forced into GET because of how browsers work :(
But that's the point of doing WebDAV, yes?
Maybe DELETE is a bad example. Let's try PUT. Browsers don't really do
PUT, either. But afaik compliant WebDAV servers and clients have to
support PUT.
So for a browser-based app, to create a new member of the /articles
collection, you might do:
GET /articles/?action=new
(which isn't idempotent, by the way!)
but with a WebDAV client (either of the MS Folders style or a servlet
that's using a WebDAV client library), you do:
PUT /articles/new-member-uri
Which for some collections may actually create a new file in a
filesytem, or it may do an "INSERT INTO table VALUES ...", or it may
do something altogether different, perhaps creating a new item in an
LDAP store.
I'm suggesting that WebDAV offers a very nice HTTP interface for
managing all sorts of collections, and that seems to be the clear
implication of the DAV developers *resisting* the assumption that DAV
is really just about managing filesystems and source resources.
I feel the same
ian> about /articles/500/printable -- I think that should be
ian> /articles/500?printable or somesuch.
This need to impose *one* view of how to build URI interfaces is
interesting. I don't think it really gets us anywhere, since it's not
especially germane to implementing DAV. Tastes and styles and
approaches legitimately differ.
To
ian> put an action in the URL implies that it's a unique resource,
ian> not a form of a resource that's available under a different
ian> URL.
I don't agree with this as a general principle, but &shrug; -- it's
also not especially relevant, as far as I can see. I regret getting
off into the URI interface design discussion, since the DAV spec is
very clear to not dictate any particular approach, which is, in my
view, one of its strengths.
ian> I'm saying the GET form shouldn't look like it's pointing at a
ian> completely different URL than the DELETE form.
I don't understand this objection, Ian. How are the following HTTP
methods "pointing at completely different URLs"?
GET /a/b
DELETE /a/b
?
All the URI/URL RFCs say pretty clearly that if the path-component of
a URL contains "/" separators, the only thing that implies is a
hierarchical relationship (which is strictly about the Base URI
algorithms and resolving relative URIs); it does *not* and should not
imply anything else, nor should we infer anything else *generally*.
>From RFC 1630,
HIERARCHICAL FORMS
The slash ("/", ASCII 2F hex) character is reserved for the
delimiting of substrings whose relationship is hierarchical.
This enables partial forms of the URI. Substrings consisting of
single or double dots ("." or "..") are similarly reserved.
The significance of the slash between two segments is that the
segment of the path to the left is more significant than the
segment of the path to the right. ("Significance" in this case
refers solely to closeness to the root of the hierarchical
structure and makes no value judgement!)
Note
The similarity to unix and other disk operating system filename
conventions should be taken as purely coincidental, and should
not be taken to indicate that URIs should be interpreted as
file names.
And a bit further down:
QUERY STRINGS
The question mark ("?", ASCII 3F hex) is used to delimit the
boundary between the URI of a queryable object, and a set of
words used to express a query on that object. When this form is
used, the combined URI stands for the object which results from
the query being applied to the original object.
...
The query string represents some operation applied to the
object, but this specification gives no common syntax or
semantics for it. In practice the syntax and sematics may
depend on the scheme and may even on the base URI.
So there are at least two ways to represent a variant of a resource:
as a less significant resource or as an operation applied to a
queryable object. I don't see that either of them is *universally* to
be preferred, even if the query string form is more often used.
As I said earlier, *this* is really a moot issue in the context of how
to implement DAV in Webware, both by the fact that DAV doesn't seem to
care *which* URL interface pattern one implements and by RFC 2295
(which really is, IMO, the *right* way to do this).
>> However, digging into the DAV RFC more, I've noticed that the
>> framework can do more than parse requests, build responses, and
>> route them to the right spots; I think it can include a good deal
>> of the resource property management stuff and the lock
>> management.
ian> Definitely... at least once we have WebDAV working at all :)
ian> Property management and locking is something I think we can
ian> forget for the first version.
For a non-compliant prototype, sure. But not for the first *compliant*
version, though. Property management is required for a Class 1
compliant implementation. The locking is not required for Class 1,
however. See, for example, 8.1 PROPFIND: "All DAV compliant resources
MUST support the PROPFIND method and the propfind XML element ...";
and 15 DAV Compliance Classes.
>> There's actually a section in the DAV RFC that talks about
>> this... 5.4 Source Resources and Output Resources.
ian> Ah, yes, good reference. So while you might browse to
ian> /articles/500, you might access /manage/articles/500 to get and
ian> save the actual source of the article (sans all superfluous
ian> styling).
I find it more helpful if we use the HTTP methods with the URIs...
So if you mean by "save the actual source of the article",
PUT /manage/articles/500
sure, that's one way of doing it.
But so is
PUT /articles/500
Or, sequentially,
GET /articles/500/source #authentication controlled
PUT /Editors/Staging/Kendall/500 #makes a copy in my workflow space
PUT /articles/500
Or, sequentially,
COPY /articles/500/source #auth controlled
Host: ...
Destination: http://my.com/Editors/Staging/Kendall/500
GET /Editors/Staging/Kendall/500
PUT /articles/500
In other words, DAV doesn't dictate the API or semantics *at this
application level*, neither should we, IMO.
ian> I think mod_dav is appropriate for filesystem-based source
ian> resources, with minimal access control (via .htaccess). With
ian> WebDAV, I think *all* access will be primarily for source
ian> resources -- modifying an output resource is not useful, since
ian> you can't save it if it's dynamically generated.
Cool, we found out where we disagree, which is important. :>
I do think it makes sense to use DAV to manage output resources, and
the DAV RFC seems to imply as much, too. It says, in section 5.4, "if
remote editing of the source resource(s) is desired, the source
resource(s) should be given a location in the URI namespace" -- which
we both do above, you by putting them at /manage/articles/500/source,
and me by putting them at /articles/500/source.
5.4 further says, "This source location should not be one of the
locations at which the generated output is retrievable, since in
general it is impossible for the server to differentiate requests for
source resources from requests for process output resources."
If managing both source and output resources with DAV weren't a DAV
RFC objective, distinguishing between them would be odd.
I agree that managing source resources is probably the most common
case, and that it's the obvious thing everyone thinks of doing when
they think of WebDAV. But it seems to me that it's also a very nice
API for doing higher, application level management of web apps,
especially RESTish ones.
I don't think
ian> source/output resources is the distinction you are looking for.
It may not be, but that is more a point about terminology. If the
distinction between source resource, output resource, and *logical*
resource works better, I'll use that. That mirrors a bit more nicely
what I'm getting at, I guess, since we have at least three things:
1. some source resources that handle GET /articles/500
2. the output resource that GET /articles/500 returns
3. the logical or biz-rules object that exists, implicitly or
explicitly, in (1)
I'm merely asking that if Webware adds WebDAV support that it not make
too many unnecessary assumptions about (3), since some of them aren't
generalizable.
Best,
Kendall Clark
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
