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

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.