Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?

On 08/26/2015 11:17 AM, Stephan Bergmann wrote:
> 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:

...

> 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.

Exactly, users discovered dav/davs worked all right so they used them, 
not bothering on the why they where used in the first place (an example 
that probably count as regression [1]).

> 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.

agreed, more confusion that's sure.

> 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?

IMHO adding the scheme vnd.sun.star.webdavs whould be good, in the end 
having the pair vnd.sun.star.webdav/vnd.sun.star.webdavs reserved for 
local interaction (e.g. browser =-> LO) activating the UCP WebDAV 
protocol over http/https.

In this way it will be the same for all the platform.

--
Kind Regards,
Giuseppe Castagnoaka beppec56
Acca Esse http://www.acca-esse.eu
giuseppe.castagno at acca-esse.eu
[1] https://bugs.documentfoundation.org/show_bug.cgi?id=93327