You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Wechner <mi...@wyona.com> on 2005/10/24 17:32:45 UTC
[RT] WebDAV integration
Hi
Edith and I are still working on an improved WebDAV implementation for
1.4-dev
and the problem we are facing is basically the problem to differentiate
between what is a common HTTP and what is WebDAV and another problem is
"source vs rendered" (also see
http://www.zope.org/Documentation/Articles/WebDAV)
This has been discussed before, but we never really took action, so I
would like to suggest two proposal which seem to workaround this problem:
1) Introduce the area "authoring-webdav"
2) Use PROPFIND to recognise a WebDAV connection and put it into the session
3) would be a different port as the Zopies seem to use, but I really
think this is a bad idea, because not everyone can open ports
arbitrarily and one has to remember a port, so I don't really want to
suggest the port solution ;-)
Well, anyway, my favorite is the PROPFIND method, but I am not sure what
problems we might encounter.
WDYT?
Thanks
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [RT] WebDAV integration
Posted by Michael Wechner <mi...@wyona.com>.
Doug Chestnut wrote:
>
>
> Michael Wechner wrote:
>
>> Hi
>>
>> Edith and I are still working on an improved WebDAV implementation
>> for 1.4-dev
>> and the problem we are facing is basically the problem to
>> differentiate between what is a common HTTP and what is WebDAV and
>> another problem is "source vs rendered" (also see
>> http://www.zope.org/Documentation/Articles/WebDAV)
>
> I had a quick look at the odt type and thought about this (source vs
> rendered) a little. It seems like there should be a way to get a list
> of all the available (via web-dav) extension/mime-type pairs from a
> resource type. And have a page2{ext}.xsl and {ext}2page.xsl for each.
>
> It would be great to have PROPFIND list
> /{pubid}/authoring-webdav/document_en.html
> /{pubid}/authoring-webdav/document_en.xhtml
> /{pubid}/authoring-webdav/document_en.odt
> ...
>
> The .html ext could be the "rendered" view of the document, on PUT
> gets passed through a transform which extracts the content. The
> .xhtml ext could be another rendered look, something like the raw
> xhtml resource type. The .odt ext could be opened in Open Office and
> saved.
right
>
> The ability to present the client with a "rendered" view of a resource
> the ability to validate the resource, and the possibility of executing
> workflow events are the only advantages that I see for having the
> webDAV layer in Lenya
also Access Controlling and re-use and ... ;-)
> (Doesn't Jackrabbit have webDAV interface?).
there exists a WebDAV contribution on top of Jackrabbit:
http://svn.apache.org/repos/asf/incubator/jackrabbit/trunk/contrib/jcr-server
This would be another possibility, but all the transformations you are
writing above are probably better handled within Lenya
> Each content manager has their favorite editor, the beauty of webDAV
> is to allow them the choice. :)
exactly, whereas it would help if the client would identify itself ;-)
I guess we have to talk to the OOo guys ...
>
>>
>> This has been discussed before, but we never really took action, so I
>> would like to suggest two proposal which seem to workaround this
>> problem:
>>
>> 1) Introduce the area "authoring-webdav"
>
> I think this would have the most promise. Use ACLs of the authoring
> area, any request for /{pubid}/authoring-webdav/** would be from a
> webDAV client (HTTP Basic auth, webDAV usecases,...).
it's probably the most simple to implement
>
>
> The problem with sessions still exists (every DAV request creates a
> new session, since the client authenticates every request), not really
> sure how to get rid of this.
this is a real problem. I guess that's a problem of the client, that
it doesn't handle sessions properly and I guess it's a hopeless fight
for the near future. Maybe in the long run clients will improve ...
>
> We could also have an "live-webdav" area could init workflow events:
> DELETE /{pubid}/live-webdav/** could deactivate a document
>
> COPY /{pubid}/authoring-webdav/index.html HTTP/1.1
> Host: myhost.com
> Destination: http://myhost.com/live-webdav/index.html
>
> -could publish a document.
ok, but I am afraid that this lead too quite some complications ...
>
>>
>> 2) Use PROPFIND to recognise a WebDAV connection and put it into the
>> session
>
> Should probably match on all the webDAV specific methods ("OPTIONS",
> "PUT", "PROPFIND", "MKCOL", ...).
>
> I looked at the possibility of just matching on one of these (usually
> "OPTIONS" method is the first request from a DAV client) and then
> using the session after the first request (need to recognize the
> client as DAV even for GET, POST, etc methods. Most DAV clients
> didn't seem to support sessions, didn't like redirects, and didn't
> care for GET parameters.
although it would have been elegant solution I guess we cannot because
of the session problem.
Thanks
Michi
>
>
>>
>> 3) would be a different port as the Zopies seem to use, but I really
>> think this is a bad idea, because not everyone can open ports
>> arbitrarily and one has to remember a port, so I don't really want to
>> suggest the port solution ;-)
>
> This was the easiest to set up (using jetty), but I agree that it is
> not a good solution since the port is specific to the servlet container.
>
>>
>> Well, anyway, my favorite is the PROPFIND method, but I am not sure
>> what problems we might encounter.
>>
>> WDYT?
>>
>> Thanks
>>
>> Michi
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [RT] WebDAV integration
Posted by Doug Chestnut <dh...@virginia.edu>.
Michael Wechner wrote:
> Hi
>
> Edith and I are still working on an improved WebDAV implementation for
> 1.4-dev
> and the problem we are facing is basically the problem to differentiate
> between what is a common HTTP and what is WebDAV and another problem is
> "source vs rendered" (also see
> http://www.zope.org/Documentation/Articles/WebDAV)
I had a quick look at the odt type and thought about this (source vs
rendered) a little. It seems like there should be a way to get a list
of all the available (via web-dav) extension/mime-type pairs from a
resource type. And have a page2{ext}.xsl and {ext}2page.xsl for each.
It would be great to have PROPFIND list
/{pubid}/authoring-webdav/document_en.html
/{pubid}/authoring-webdav/document_en.xhtml
/{pubid}/authoring-webdav/document_en.odt
...
The .html ext could be the "rendered" view of the document, on PUT gets
passed through a transform which extracts the content. The .xhtml ext
could be another rendered look, something like the raw xhtml resource
type. The .odt ext could be opened in Open Office and saved.
The ability to present the client with a "rendered" view of a resource
the ability to validate the resource, and the possibility of executing
workflow events are the only advantages that I see for having the webDAV
layer in Lenya (Doesn't Jackrabbit have webDAV interface?). Each
content manager has their favorite editor, the beauty of webDAV is to
allow them the choice. :)
>
> This has been discussed before, but we never really took action, so I
> would like to suggest two proposal which seem to workaround this problem:
>
> 1) Introduce the area "authoring-webdav"
I think this would have the most promise. Use ACLs of the authoring
area, any request for /{pubid}/authoring-webdav/** would be from a
webDAV client (HTTP Basic auth, webDAV usecases,...).
The problem with sessions still exists (every DAV request creates a new
session, since the client authenticates every request), not really sure
how to get rid of this.
We could also have an "live-webdav" area could init workflow events:
DELETE /{pubid}/live-webdav/** could deactivate a document
COPY /{pubid}/authoring-webdav/index.html HTTP/1.1
Host: myhost.com
Destination: http://myhost.com/live-webdav/index.html
-could publish a document.
>
> 2) Use PROPFIND to recognise a WebDAV connection and put it into the
> session
Should probably match on all the webDAV specific methods ("OPTIONS",
"PUT", "PROPFIND", "MKCOL", ...).
I looked at the possibility of just matching on one of these (usually
"OPTIONS" method is the first request from a DAV client) and then using
the session after the first request (need to recognize the client as DAV
even for GET, POST, etc methods. Most DAV clients didn't seem to
support sessions, didn't like redirects, and didn't care for GET parameters.
>
> 3) would be a different port as the Zopies seem to use, but I really
> think this is a bad idea, because not everyone can open ports
> arbitrarily and one has to remember a port, so I don't really want to
> suggest the port solution ;-)
This was the easiest to set up (using jetty), but I agree that it is not
a good solution since the port is specific to the servlet container.
>
> Well, anyway, my favorite is the PROPFIND method, but I am not sure what
> problems we might encounter.
>
> WDYT?
>
> Thanks
>
> Michi
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org