On Thu, 2002-04-25 at 12:16, Kendall Clark wrote: > I wonder if we might not just use some kind of callback scheme? If > you want a servlet to handle PUT or DELETE or COPY, you have to > implement and register a method that is called as needed. > > In the same way that GET causes one kind of thing when handed a URI > that ultimately maps to a filesystem entity, and another kind of thing > when ultimately it maps to a database SELECT and Cheetah template > transform, the WebDAV HTTP extensions are going to show the same > variability, doing one thing when pointed at *your* /wk/Edit/500 URI > and something else when pointed at my /articles/500.
Assuming that /articles/500 is a "resource" that you might want to version, /articles/ might be a controller servlet that manages access to its children, and anything after 500/ would be a property or an action. In such a case it would make perfect sense to allow the /articles/ servlet to answer the WebDAV request (since 500/ might not even exist in a filesystem). WebDAV is a layer of abstraction that presents a filesystem to its client. /articles/ (or a WebDAV aware delegate) is another layer of abstraction that presents a filesystem to WebDAV. If /articles/500/foo-component/ is itself a version-able resource, /foo-component/ might be yet another servlet that could provide the same WebDAV responses. > Then, the WebDAV implementation in WebKit mostly handles the XML > parsing, request routing, and returning whatever the callback method > returns. Otherwise, I don't see how we can implement PUT, DELETE, COPY > in a way that generalizes to all Webware URIs. > > We could just treat the underlying servlet, PSP, Cheetah, > et. al. resources as static files; i.e., DELETE /wk/index.psp simply > deletes 'index.psp' from the filesystem; but if that's the approach, > why not just use mod_dav? Yes, mod_dav is more appropriate for that purpose, but that would be for application *developers* not application *users*. The two uses are orthogonal. > The other alternative is to assume some generlish workflow semantics > for WebDAV methods and then users of Webware have to fit into that > range of assumptions, but that strikes me as antithetical to the > notion of Webware as a framework. That is exactly why we should not try too hard to find something "that generalizes to all Webware URIs". Let the servlet/container manage its own namespace. > >From the point of view of HTTP, GET is idempotent and "always" just > returns the present state of the URI. But on the server side, what > constitutes the present state of the URI, and *how* it's constituted, > is (or can be, anyway) URI-specific, and as far as I can tell that > goes for WebDAV methods, too. That is why /articles/ should not expose 500/delete as a GETtable resource to a WebDAV client. That kind of knowledge need not be available outside of the servlet. It is also why /delete is better spelled as /?action=delete: A conservative spider would probably skip the latter. /print might be acceptable instead of /?view=printable, because it probably is idempotent w.r.t. GET, but it probably doesn't make sense to WebDAV it because it is not an independent resource, but merely a view. Note: Deficiencies in Webware's current handling of the URI space surface when you start trying to divorce URIs from the filesystem. My frustrations in trying to create a workflow app based on this abstract resource view is what motivated me to create URLDecoder (http://jaguar.sourceforge.net/webware/urldecode.html) over a year ago. Catalina's URI mapping is even better, because it is completely controlled by servlets and containers managing their own private namespaces, instead of Application.serverSidePathForURL() trying to be all-wise and all-knowing. Contexts were a step in the right direction, but only a step. _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
