Open Bug 13383 Opened 25 years ago Updated 6 years ago

Support WebDAV protocol for publishing (revision, etc.; Composer-specific UI and code)

Categories

(SeaMonkey :: Composer, enhancement)

Product:
SeaMonkey
Component:
Composer
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: cvrc, Unassigned)

References

Details

(Keywords: helpwanted) 

As noted in WebDAV mailing list,
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0151.html
thre is some interest in this feature.

WebDAV protocol (RFC 2518) http://www.ietf.org/rfc/rfc2518.txt has a
broad support in web publishing clients such as IE 5.0/FrontPage, as well
as in servers such as IIS 5.0 and in Red Hat Linux E-Commerce Server
http://www.redhat.com/about/1999/press_ecommerce.html
Status: NEW → ASSIGNED
Target Milestone: M20
cvrc@netscape.com: This bug is assgned to you. Do you want to work on this bug ?

matti@epost.de - I suggest that, if you want to work on this bug, you go right
ahead. I think Murthy is no longer in a position to work on this...

Gerv
I called Murthy and he hasn't time to work on this. I am reassigning it to the
owner of the Editor component.

This would be a feature which really made Mozilla's Composer stand out from the
crowd. It would also be extremely useful if and when www.mozilla.org becomes
Zope-based, because it would allow easy publishing of docs.

Gerv
Assignee: cvrc → brade
Status: ASSIGNED → NEW
Keywords: mozilla1.0
Future; I don't have time to do this for the forseeable future but I'd love to 
see someone do it
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: --- → Future
spam composer change
Component: Editor: Core → Editor: Composer
Would be very nice if Mozilla Composer could have a module to allow a
third-party application to install a module that could handle publishing, etc.
For example a composer "plugin" that install WebDav support, other corporate
proprietary publishing solutions, etc. 
I would love to have this feature.  I wonder what it would take.
(reference http://bugscape.netscape.com/show_bug.cgi?id=10837 for customer needs)
Do we need a separate bug for WebDAV support in browser or should this bug cover 
both Composer and browser?

( Hey, does this mean that Netscape might be interested in WebDAV? )

If you are going to do this you probably want a meta bug for all the little
subtasks, right?  Might as well make this the meta bug and go from there.
Hi Guys,

 this so needs to done. Dav is a godsend when it comes to sysadmins not 
wanting to install ftp onto their already vulnerable webservers...
Microsofts (botched?) implementation in webfolders (all five variants) seem to 
work ok, but each installation seems to behave differently. An the fact that 
just about the only microsoft product that DOES NOT use webDAV is frontpage is 
kind of ironic. Put the boot in :)





I don't see this happening for mozilla 1.0; removing keyword.
Keywords: mozilla1.0
Another thing that would be nice is if mozilla, the browser, supported the
launch of a web folder the way IE does.  

IE launches a web folder if your link is:

<a href="blah" folder="http://www.foobar.com/dav">This is a folder</a>
WebDAV is basically a servelt/cgi protocol on top of HTTP. As such, it 
should not be too hard to add some basic functions.

The OEONE calendar has added a WebDAV upload function and 
managed to do so completely in JavaScript -- see 
"http://lxr.mozilla.org/mozilla/source/calendar/resources/content/calendarP
ublish.js". (Apologies if there are errors in this reference -- it was what I 
was told on #calendar at irc.mozilla.org.)

Adding repositiory browsing, checkout and locking would be more 
complex, but probably not enormously so. The existing RDF browsers in 
Mozilla could be fed a data stream converted from WebDAV repository 
information.
I learned yesterday that the Xopus (http://xopus.org/) open source XML editor
that runs in the browser content area recently got WebDAV support (not complete,
just what you minimally need in an editor); it took some 20 lines of JavaScript!
So who can whip up a patch for Mozilla?
Heikki--Please paste the 20 lines of JS here; I couldn't find them on the
website (perhaps it was on one of the broken links?).  In particular, it'd be
helpful to know which particular aspects of webdav are desirable.

Tim Maroney--(gee, that JS looks familiar--and ancient) The mozilla/calendar
"publishing" functionality is based on early work for publishing for Composer. 
That work is essentially completed now in Composer.  If you consider
mozilla/calendar to support webdav, Composer also supports webdav so this bug
can be resolved fixed.

Clearly, I need more guidance as to what particular features are desirable. 
It's not going to happen all at once.
Wouldn't the intention of the bug be more along the lines of adding a general
API for supporting webdav, than just hardcoding a couple of commands?
The Calendar code was copied from Composer, so there nothing new for Composer 
in there.
You can 'publish' to WebDAV with the current Composer, simply by setting the 
webdav url as publishing address, and set login information.
Maybe a smal label/help entry about what can and can't be done with 
Mozilla/WebDAV could be helpfull
1) IMHO the eruption of wonderful discussion is misplaced. (No, I don't have an 
alternative to suggest immediately). This, after all, is a bug report.
2) The obvious elegance of DAV belies some gnarly problems. I heartily suggest 
advocates visit some of the working docs cited on 
http://ftp.ics.uci.edu/pub/ietf/webdav/ and http://www.webdav.org/ ... the 
project involves some tastey aspects, e.g. file locking. The working group's 
notes are especially revealing.
Tally ho! 
First time commenter.  Let's see what happens. :^)

I've been working on a small JS lib from DAV in Moz.  Basically, connect to 
a DAV server (OPTIONS), get the items in a folder (PROPFIND), fill an RDF 
graph with the contents, present a tree, retrieve an item (GET), edit it 
in, then send it back (PUT).

I've learned a bit so far.  First, stay away from createDocument on OS 
X. :^)  Second, the serializer makes up its own namespace prefixes, which 
is OK, but my DAV server (Zope) expects "D:" everywhere.  Third, I *really* 
wish I was competent enough to write a real datasource to encapsulate 
the semantics.

Regarding the assertions that Composer or Calendar do WebDAV, I think that's 
a mistatement.  They do HTTP GET and PUT.  That's not DAV.  That doesn't 
mean that it isn't useful, but the DAV specs provide specific descriptions 
for levels of support.

IMO, the biggest part of DAV that needs implementing is PROPFIND.  This will 
allow server resources to be discovered in a way similar to local files.  
You can then populate an RDF datasource from this content.  After PROPFIND, 
I'd vote for DELETE (this is actually HTTP, not added in DAV), then PROPATCH, 
then the locking stuff.  Well, I suppose that OPTIONS (from HTTP I think) are 
necessary to build a reliable client.  Later, all LOCK/UNLOCK.

All this can be done today in JavaScript for Moz or IE.  I'm more 
interested in the integration into Moz the platform.  With little prompting 
I can generate a few hundred suggestions generating several man-months of 
effort. :^
-->
Assignee: brade → composer
Status: ASSIGNED → NEW
a behavior like ie6 does on windows would be really great, try the following, 
which opens the webdav/deltav tree in an explorer window and you can drag and 
drop.

the example goes to a subversion repository (subversion.tigris.org). subversion 
does not support locking, so direct open with a text editor should not work.

<html>
 <head>
         <style>
                 A {behavior: url(#default#AnchorClick);}
         </style>
 </head>
 <body>
 <a href="http://svn.collab.net/repos/svn/"
 folder="http://svn.collab.net/repos/svn/"
 target="_blank">open in web folder view!</a>
 </body>
 </html>
I agree that it would be extremely useful if Mozilla would support the so-called
webfolder behaviour implemented by IE.

Some thoughts:

- As long as Mozilla doesn't have it's built-in WebDAV client (and maybe it
doesn't need that), it would be fine if this would just invoke some
platform-dependant code (such as a "webfolder" in Windows, or mounting as a
network share using MacOS X).

- Is the extension chosen by Microsoft (a CSS behaviour) ok? Otherwise it would
be interesting to discuss alternate approaches -- fopr instance a text/html view
of a DAV collection might specify that a user will prefer to see that resoure
through a DAV client instead of the HTML representation).

Why is this a Composer bug?  Seems to be Networking to me.  FWIW, there is a way
to send messages through Hotmail directly with WebDAV I believe.
Assignee: composer → darin
Component: Editor: Composer → Networking
QA Contact: sujay → benc
aaron: webdav is a protocol built on top of HTTP.  while we could perhaps
provide an abstraction layer for webdav inside the networking library, i don't
see that being completely necessary.  it seems more like an extension to me. 
i'm sure there would be more work necessary to hook up composer to talk to
whatever webdav abstraction layer we come up with than to write the actual
abstraction layer itself.  this bug seems to be a "meta" bug for making composer
support webdav, so if that involves filing a new bug to create a webdav
abstration layer, so be it.  this is not that bug.

-> composer
Assignee: darin → composer
Component: Networking → Editor: Composer
QA Contact: benc → petersen
Okay, bug 212342 added for global WebDAV support.
Seems to me that WebDAV for composer is already there (comment 18) so what is
this bug for, exactly?
If this is really a meta-bug, won't other apps run into the same implementation
problems?
Depends on: webdav
For me, the most important missing feature of composer, is not supporting
multi-user publishing. This could be solved by using webdav locks. It could then
replace (when adding a remote file browsing) in lots of companies Frontpage as
web publishing tools.

I'm quite sure that lots of sysadmin would be very happy to replace frontpage by
webdav/mozilla.

webdav locks is not available in composer. When publishing a page to a locked
ressource, you get a 'unknown error'.
Depends on: 240223
Hello,
I recently discovered your products and have been using Firefox since 0.9.1.
I must say that I have been very impressed by them and keep on pushing my
friends to switch to Firefox, especially since the release of 1.0PR.

I was looking at Thunderbird's feature and the only reason for me not to switch
to your email client (which seems to be great) is because it doesn't support Web
Dav so I can't access my hotmail account.

I would like to think thant I am not the only one in this position.
Would it be possible to implement only what is needed for such connectivity?

Daniel Desjardins (comment 28) -- I think you should file a new bug or look at
Thunderbird-specific bugs.  This bug is for Mozilla's Composer application
(creating, editing, publishing of html documents) and has nothing to do with
e-mail.  The people who are working on Thunderbird are almost certainly not cc'd
on this bug (nor should they be).

For the record, Composer does support publishing via ftp and http put.  This bug
is for it to handle webdav items such as revisions (see comments 19, 23, 26 and
others).

Aaron Kaluszka (comment 26) -- This bug, specifically for Composer would include
such things as adding / changing dialogs and other UI to handle revisions (if
you want to edit an old revision?).  It would also include any api changes to
Composer's JS which will need to be made to use the new webdav api.
Summary: Support WebDAV protocol for publishing → Support WebDAV protocol for publishing (revision, etc.; Composer-specific UI and code)
FWIW: I'm currently working on partial WebDAV implementation in JavaScript and
I'm getting along quite fine. I have GET, PUT, DELETE, MKCOL, COPY, MOVE,
PROPFIND and PROPPATCH working, I plan to release quite soon, after that I want
to tackle locking, and in the future hopefully I can tackle (a subset of) DeltaV
and DASL. This is all done using XMLHTTPRequest, and because it uses a custom
XML parser that properly handles namespaces it works on both Moz and IE
(hopefully also on Safari, not tested though). It may not directly solve this
bug, but you may find it useful as an example, or perhaps you can use the lib
directly from Composer (not sure about that, don't know anything about Composer
to be honest).
The license is an issue, since currently it's GPL licensed, but if you want I
think we can work something out... If you're interested, send an email to
(johnny@debris.demon.nl), check out my viewcvs
(http://debris.demon.nl:7080/cgi-bin/viewcvs.cgi) or keep an eye on my website
(http://debris.demon.nl)...

Cheers,

Guido Wesdorp
Product: Browser → Seamonkey
What's about this bug? Isn't it to be closed? I know SeaMonkey Composer supports WebDAV at least PUT is implemented, which is enough for the Composer, if we do not compose directly into SVN, which is not the typical target of the composer.
Assignee: composer → nobody
Priority: P3 → --
QA Contact: chrispetersen → composer
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.