Version: (using KDE KDE 3.5.1) Installed from: Ubuntu Packages I suggest dropping the use of webdav: pseudo URLs in favor of a "Webdav" checkbox near the address bar. When the checkbox is checked Konqueror should try to do a PROPFIND request instead of a GET, and if it gets an answer and the Resource is a collection display it as a folder, otherwise fall back to GET. Furthermore the items (files an folder) in a webdav-share should allow actions to be done with the URL rather than the content, e.g. launch oowriter with that http-URL, send the URL in a mail, etc. Rationale: the webdav-pseudo URLs reference the same resource as HTTP(S), the standard HTTP-URLs are more accessible as non-webdav aware clients can access them (such as with with GET and PUT).
Ops, should have been a WISH rather than Bug, don't think I can change this. Sorry.
I'd say "WONTFIX". The webdav and webdavs protocols are really useful.
No doubt that webdav is useful, the proposal is just to use the standard URI-schemes for addressing webdav-accessible resources (http and https) rather than a proprietary schema. The motivation is to get more out of the webdav support by allowing a higher level of interoperability. Webdav is an extension to HTTP and bases on HTTP Namespace model.
I meant the "webdav://" and "webdavs://" forms are very useful and I'd hate to see them go. For one thing, I don't think Konqueror should send PROPFIND for every single resource it wants off the web before it sends a GET.
My proposal is to have a checkbox near the address bar to switch between normal web-browser and webdav-mode (non PROPFINDs when disabled). This seems to me closer to the http/webdav architecture of accessing the same resources with other methods. Afaik, for webdav-uri konqueror is currently sending a PROPFIND prior to the GET, I think this would only be necessary for resources that might be collections, i.e. resources with a trailing slash in their URLs. To find out if a server supports webdav (and PROPFIND requests could be of any use) a OPTIONS request could be issued.
A checkbox in the Location toolbar? No way. It would have to be in the menus somewhere. And if anyone wants to use WebDAV, they'll have to turn it on. Which is why I don't like this idea. Which is why I don't like Microsoft's WebDAV support: if I use their browser and type https://localhost/dav, I don't see a directory listing. "webdav" as the protocol is exactly that checkbox that you want, in a nicer way.
> A checkbox in the Location toolbar? No way. It should be easy and fast to switch, as user may want to get a representation of a collection (index-page) rather than the view as a folder (but I see that an open-standard cannot pay as much do make it in the location toolbar as a big search-engine company :-). > if I use their browser and type https://localhost/dav I don't know what "Microsoft" and their browser is, but the behavior you're describing seems to me exactly like the one of konqueror (using the https URI scheme) > "webdav" as the protocol You probably mean "webdav" as proprietary URL-scheme. I wouldn't have posted this RFE if this would be exactly what I want. Let me try to summarize again: 1. Proprietary URL schemes for something there is an standard URL-scheme are a bad practice 2. It causes a duplication of URLs for resources, even for all the non-collection resources for which Konqueror does not support any different functionality in the two URL-schemes 3. It makes interoperability with other applications hard, for example using standard URLs you could copy the location and paste in the file open dialog of OpenOffice which you can't with proprietary scheme. 4. It would be nice to add URL-based functionality in the context-menu of a webdav-resource (like validate online with W3C validator, send URL as email, open with OpenOffice) which is not of much use when using a proprietary URL-scheme
I know of all those interoperability problems. I'm just saying it would be a shame to lose the "webdav" shortcut, since it's the only practical way that exists. None of the options you have presented are sufficient for all purposes. Suppose we do add a checkbox to Konqueror. What about other KDE programs or the file selector? How are they supposed to know which resource to use? I'm sorry, it's just my opinion that it's a bad practice to have the same URL refer to two different resources. It's supposed to be Universal, after all. And by "Microsoft and their browser", I mean Microsoft, Windows, Explorer and Internet Explorer. If you open a DAV folder using Windows Explorer (and you have to know how to do it, because it's not easy), you get a URL like "https://localhost/dav" on your Windows Explorer window. If you click on that URL in the Location bar and press Enter, the contents change! They now send a GET instead of a PROPFIND. This is what I mean by "two resources in one URL".
Another use-case: User opens Konqueror, clicks the "enable DAV" checkbox and browses to DAV resource "http://localhost/dav/". That gets recorded to history. Then he disables the checkbox and continues browsing. Later he opens the history and clicks the entry there, which contains the URL "http://localhost/dav/". This will show the wrong output, since it won't use the DAV extensions. If you have an idea on how to circumvent that problem, I'd like to know. And, btw, URL is supposed to be Universal, so all the information has to be on it: don't ask for a flag to be added indicating which method to use. We don't do that for POST.
> What about other KDE programs or the file selector? I guess if you access a HTTP-resource in a file-selector Webdav should be used. Usually the index-page which a user may want to open (rather than looking at the directory listing) is available at a separate location (typically index.html). > I'm sorry, it's just my opinion that it's a bad practice to have the same URL refer to two different resources No need to be sorry, not just your opinion, even I would agree :-) With webdav you are not referring to another resource but just possibly applying another HTTP-method on that resource which causes something else to be returned. HTTP-URLs do not refer to a particular representation of a resource but to a resource on which different methods may be applied, webdav extends the possible methods. But even with plain HTTP you may get a different response for the same resource, for example when using language negotiation. On the other hand, in many cases, i.e. all resources but collections, the konqueror dereferences two different URLs to exactly the same representation as for: http://www.osar.ch/2006/01/05/titel-fluchtpunkt_quer and webdav://www.osar.ch/2006/01/05/titel-fluchtpunkt_quer This duplications of URLs makes it harder to do things like merging bookmarks are doing annotations. The behavior of the software from the company you mention would not reproduced with the checkbox I propose, the resources would be shown the same way as long as you don't (un)check the box. Your history example results in the user seeing something else as she saw accessing the page the first time, I don't however agree that this is a wrong output. The same may happen when the user changes the language preferences and goes back in the history, she gets something else than she saw before. This may be irritating for some user in some cases but may be exactly what they want in other cases. Another use case would be the one of a user generally preferring webdav but which synchronizes the bookmarks with a mobile device with a non-webdav aware browser, in this case having the mobile browser doing a GET requests makes usually sense even for collection resources, as it may often result in an index-page being delivered. > URL is supposed to be Universal hu? weren't you arguing for keeping a proprietary URL scheme? > We don't do that for POST Right, do don't have different URL-schemes for GET, POST, OPTIONS, etc. but you're inventing one for PROPFIND.
But a bookmark to a webdav scheme works, whereas we would have to add some hack to the bookmark code in order to make webdav bookmarks works, if the scheme used is http://. This seems to me like a lot of trouble for little gain. As Thiago says, all the information is supposed to be in the URL.
>> URL is supposed to be Universal > hu? weren't you arguing for keeping a proprietary URL scheme? Which is why I'd rather see "webdav" standardised as a schema instead. That looks to me like the cleanest solution available.
"All information" isn't in a bookmarked URL anyway, otherways it would have to contain at least the value of the accept-language header (other candidates would be HTTP-authentication and cookies as they too may cause a different representation to be servers and maybe even the size of the browser window at the time of bookmarking as it influences what the user sees). It may be a lot of work, but that's a standard argument against implementing standards, however standards are what makes it possible to overcome factual software monopolies which is in the spirit of open source. Please go ahead and try having a "webdav:"-URL scheme registered with iana, personaly I'm convinced that you wouldn't suceed, because URIs (of which URLs are a subset) identify resources rather than particular methods to access resources.
I can't propose any solutions, but I would surely also see KDE following standards instead of breaking them.
The problem is that this webdav:/ workaround creates problems in other areas, as I see it. Security feedback: http://bugs.kde.org/show_bug.cgi?id=81847 The proprietary scheme being work-arounded: http://bugs.kde.org/show_bug.cgi?id=126847
A related problem is streaming from WEBDAV shares. While this is clearly a shortcoming of the KIO-Module, standard URI handling would make this work better. As you open a multimedia file using the webdav/webdavs pseudo-protocols, programs like kaffeine will tell you something like "Cannot find input plugin for MRL "webdav://...". At least without SSL these would be able to standard-stream the data using HTTP read-only. For HTTPS they might ask you, again, for your credentials. I hate to say but in this aspect Gnome's VFS is clearly superior. Streaming works very well with SSL over the internet, just click on the file and it opens in totem and plays nicely. There are several solutions: 1) Make every (KDE) program understand webdav/webdavs URIs and handle appropriately (non-systematic approach) 2) Switch to HTTP/HTTPS naming in order to allow backwards compatibility for programs who support it (also non-KDE programs), this has the disadvantage that these cannot use advanced WEBDAV features (locking, writing etc.) 3) Use a virtual local file system layer like GnomeVSF/FUSE that supports all of these features Just my impression but this is really what keeps users from switching to KDE from Gnome.
David said it best: (In reply to David Faure from comment #11) > This seems to me like a lot of trouble for little gain. (In reply to J.D. from comment #16) > I hate to say but in this aspect Gnome's VFS is clearly superior. Streaming > works very well with SSL over the internet, just click on the file and it > opens in totem and plays nicely. > [...] > > Just my impression but this is really what keeps users from switching to KDE > from Gnome. Yep. We hear this a *lot. See Bug 75324.