Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


On 08/25/2015 05:11 PM, Giuseppe Castagno wrote:
On 08/25/2015 03:24 PM, Stephan Bergmann wrote:
On 08/25/2015 02:51 PM, Giuseppe Castagno wrote:
On 08/25/2015 01:14 PM, Stephan Bergmann wrote:
On 08/25/2015 12:07 PM, Giuseppe Castagno wrote:
In order to use pure WebDAV and not the file system mapped one.

So in the the users will have a choice (in Linux, don't know in other
platforms):

- WebDAV file system mapped: dav:// davs://
- pure WebDAV: a choice among the others I suggested above.

I don't really understand what requires use of URL schemes different
from http/https in your users' scenarios.  But, depending on how tightly

Here it's how it's supposed to work [1].

Proved to be very difficult to open a http/https link from a browser and
have it sent to LO and not the browser itself, at least using the scarce
example I had.

Probably there is another way I don't know ATM.

I see.

you control your users' environments, another option might be to install
into their environments configuration settings (under
/org.openoffice.ucb.Configuration/ContentProviders/Local/SecondaryKeys/Office/ProviderData)

that do map the dav/davs URL schemes to the
com.sun.star.ucb.WebDAVContentProvider service (instead of implicitly
leaving them to be handled by a default-registered gnome-vfs or gio
service, if applicable, or to be left unhandled).  (Which would of
course undo for these users the fix for rhbz#1134285 mentioned above,
where applicable.)

that would be a good idea, especially in Windows where dav:// doesn't
work at all in master (checked with a daily build), and http/https links
inside a browser have difficulty same as above.

I am totally unaware how widespread use of the non-standard dav/davs URL schemes is in the wild, apart from it apparently being used by GnomeVFS and GVFS/GIO. When fixing rhbz#1134285, I noticed that support for dav/davs had only been added to the WebDAV UCP in 2008, with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=b07a5fcc600ad564315d36fbd18495184fdf69cf> "INTEGRATION: CWS tkr10: i84676 neon and gnome-vfs2" specifically as a workaround to prevent trouble when a dav/davs URL is processed by the (now legacy) GnomeVFS UCP. Therefore, I assumed it would not cause regressions to remove the bindings for dav/davs from the WebDAV UCP again now (except for the legacy GnomeVFS case), in order to fix rhbz#1134285.

However, as your scenario shows, it apparently did cause regressions. The Alfresco integration piggybacking on the b07a5fcc600ad564315d36fbd18495184fdf69cf workaround, and relying on the WebDAV UCP to be able to handle dav/davs URLs, happened to work by coincidence rather than by design.

One solution might be to generally re-bind in LO the dav/davs schemes to the WebDAV UCP on non-Linux platforms (but keep it as-is in the Linux-with-GVFS/GIO case to not break the fix for rhbz#1134285 again). A drawback is that this would cause dav/davs to be handled differently by LO depending on platform (and the GIO/GVFS stack apparently not even being able to handle it well at least in some environments, as you point out below), which could cause more confusion than bring good.

Another, less brittle solution (as already mentioned in this thread) could be to introduce in LO a non-standard vnd.sun.star.webdavs scheme to complement the non-standard vnd.sun.star.webdav scheme, and use those instead of dav/davs in your scenario. Would that be a possible solution for you?

Finally, ATM on Linux (Ubuntu 14.04) the gio service complained the
share was not WebDAV while it actually was, see the warnings on the
first message of this thread, so I wasn't able to see it at work.

That would presumably be an issue with Ubuntu's GIO/GVFS stack.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.