On Wednesday 11 June 2003 05:13, you wrote:This is probably not the appropriate venue for a discussion on webDAV, but I feel that this type of work-around, which I use, is not appropriate. I think that there will need to be an addition to HTTP, which will define the difference between a GET for viewing content, and a GET for publishing... Since webDAV is a standard, it should be possible to argue the need for such a device. If we can get that device introduced into HTTP, then after a time, client applications will be altered to work thus, and voila!!
Trevor Phillips wrote:
I'm quite suprised at the limited amount of custom DAV server uses. II think the problem with webDAV, as a protocol through which to
mean, here's a protocol for editing content over HTTP, which to me
screams as an ideal solution for, say, editing full HTML content within a
DB/CMS.
manipulate web pages, lies in the fact that it is difficult to
manipulate dynamic content without sending the rendered content to the
client, instead of the true source. (Phew!! That was long winded... :P
) The only way that I have found to do it, is to either break the web
server, (ie publish to a web server that doesn't have the dynamic
language engine installed), or... (I don't know of another solution that
works... :( )
I'm aware of the issue, but don't see it as a show-stopper. You could use an alternate URL to direct DAV handling to a different handler. ie; To view: /path/to/content/
To edit: /dav/path/to/content/
... where the module associated with /dav/ knows how to retrieve the raw content (be it files, or a map to DB-stored content) of the normal path.
When viewing the content, you could provide links to the "edit" version of the URL.
Until then, I find this approach to be less than satisfactory....
speeves cws
