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

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:
> > Punchline: use standard http/https URL schemes instead of non-standard
> > dav/davs ones.
>
> I know, I know :-)
>
> But the main reason for asking is the way our users employ the dav://
> and davs:// schemes in local interaction with a browser, as in this [1].
>
> So probably something else is needed in local use only.
>
> The internal scheme vnd.sun.star.webdav: may be used, though misses the
> https:// counterpart (vnd.sun.star.webdavs: ?).
>
> Or something entirely new: vnd.tdf.org.dav: / vnd.tdf.org.davs: ? :-)
>
> 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 
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.)