Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?
On 08/27/2015 07:34 PM, Giuseppe Castagno wrote:
I wonder if in INetURLObject I can put a single method like this:
bool INetURLObject::IsWebDAV()
{
return ( hasScheme( http ) ||
hasScheme( https ) ||
hasScheme( vnd.sun.start.webdav ) ||
hasScheme( vnd.sun.start.webdavs ) );
}
to have this test in a single place? Currently I repeat it four times.
Sure, or maybe something more descriptive like isAnyWebDavScheme (so
casual readers don't erroneously assume it only checks for
vnd.sun.star.webdav). Also, for schemes known in INetProtocol, feel
free to use the hasScheme(INetProtocol) overload, which should be
slightly faster (which is likely negligible) and less prone to typos.
Finally, looking at the code in INetURLObject I noticed this comment:
http://opengrok.libreoffice.org/xref/core/tools/source/fsys/urlobj.cxx#114
and this chunk of code:
http://opengrok.libreoffice.org/xref/core/tools/source/fsys/urlobj.cxx#335
should vnd.sun.star.webdavs be added as well?
No, all that is only about those schemes that INetURLObject has intimate
knowledge of. Traditionally, for any URL scheme to be usable in LO it
needed to be added to INetURLObject, with scheme-specific parsing
support and all (and that is how the rather random collection of schemes
in INetProtocol came about over time). But that is largely unnecessary
today.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?
On 08/27/2015 03:27 PM, Giuseppe Castagno wrote:
On 08/27/2015 01:37 PM, Stephan Bergmann wrote:
On 08/27/2015 12:35 PM, Giuseppe Castagno wrote:
Saw commit [1], probably INetProtocol needs adjusting too.
Don't think so. Since INetURLObject falls back to INetProtocol::Generic
now, there's rarely need these days to keep adding schemes to
INetURLObject/INetProtocol. (For example, dav and davs are not
there, either.)
Then, while checking for the scheme of a url to determine if it's webdav
or not, in SfxMedium::LockOrigFileOnDemand and SfxMedium::UnlockFile I
used:
INetProtocol aProto = GetURLObject().GetProtocol();
if( aProto == INetProtocol::Http || aProto == INetProtocol::Https ||
aProto == INetProtocol::VndSunStarWebdav )
{
// WebDAV !
}
Or is there another way to detect the protocol ?
Yeah, only after pressing send I understood that your probably
INetProtocol needs adjusting too was meant in the context of your
pending https://gerrit.libreoffice.org/#/c/17189.
See https://gerrit.libreoffice.org/#/c/18060/ for tentative new
functionality to allow to easily check also for an
INetProtocol::Generic's INetURLObject scheme. And feel free to push in
combination with your 17189 if it proves useful for your needs.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?
On 08/27/2015 01:37 PM, Stephan Bergmann wrote:
On 08/27/2015 12:35 PM, Giuseppe Castagno wrote:
On 08/27/2015 11:45 AM, Stephan Bergmann wrote:
So added support for vnd.sun.star.webdavs to LO 5.1 now,
https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/5.1oldid=116154#Core.
Saw commit [1], probably INetProtocol needs adjusting too.
Don't think so. Since INetURLObject falls back to INetProtocol::Generic
now, there's rarely need these days to keep adding schemes to
INetURLObject/INetProtocol. (For example, dav and davs are not
there, either.)
Then, while checking for the scheme of a url to determine if it's webdav
or not, in SfxMedium::LockOrigFileOnDemand and SfxMedium::UnlockFile I used:
INetProtocol aProto = GetURLObject().GetProtocol();
if( aProto == INetProtocol::Http || aProto == INetProtocol::Https ||
aProto == INetProtocol::VndSunStarWebdav )
{
// WebDAV !
}
Or is there another way to detect the protocol ?
For example one may be this:
::ucbhelper::Content aContent;
OUString aScheme;
aContent = ::ucbhelper::Content(sURL, xCommandEnv,
comphelper::getProcessComponentContext());
css::uno::Reference css::ucb::XContentIdentifier xContId(
aContent.get().is() ? aContent.get()-getIdentifier() : 0 );
if ( xContId.is() )
aScheme = xContId-getContentProviderScheme().toAsciiLowerCase();
if ( aScheme == http || aScheme == https || aScheme ==
vnd.sun.star.webdav )
{
// WebDAV !
}
what's the better?
This is where I got the idea:
http://opengrok.libreoffice.org/xref/core/sfx2/source/doc/docfile.cxx#385
Perhaps another better way?
Thanks
--
Kind Regards,
Giuseppe Castagno aka beppec56
Acca Esse http://www.acca-esse.eu
giuseppe.castagno at acca-esse.eu
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?
On 08/27/2015 03:37 PM, Stephan Bergmann wrote:
On 08/27/2015 03:27 PM, Giuseppe Castagno wrote:
On 08/27/2015 01:37 PM, Stephan Bergmann wrote:
On 08/27/2015 12:35 PM, Giuseppe Castagno wrote:
Saw commit [1], probably INetProtocol needs adjusting too.
Don't think so. Since INetURLObject falls back to INetProtocol::Generic
now, there's rarely need these days to keep adding schemes to
INetURLObject/INetProtocol. (For example, dav and davs are not
there, either.)
Then, while checking for the scheme of a url to determine if it's webdav
or not, in SfxMedium::LockOrigFileOnDemand and SfxMedium::UnlockFile I
used:
INetProtocol aProto = GetURLObject().GetProtocol();
if( aProto == INetProtocol::Http || aProto == INetProtocol::Https ||
aProto == INetProtocol::VndSunStarWebdav )
{
// WebDAV !
}
Or is there another way to detect the protocol ?
Yeah, only after pressing send I understood that your probably
INetProtocol needs adjusting too was meant in the context of your
pending https://gerrit.libreoffice.org/#/c/17189.
See https://gerrit.libreoffice.org/#/c/18060/ for tentative new
functionality to allow to easily check also for an
INetProtocol::Generic's INetURLObject scheme. And feel free to push in
combination with your 17189 if it proves useful for your needs.
worked like a charm! Thanks Stephan, I'll add it to my patch set list,
that will became three patch long, yours the first.
I wonder if in INetURLObject I can put a single method like this:
bool INetURLObject::IsWebDAV()
{
return ( hasScheme( http ) ||
hasScheme( https ) ||
hasScheme( vnd.sun.start.webdav ) ||
hasScheme( vnd.sun.start.webdavs ) );
}
to have this test in a single place? Currently I repeat it four times.
Finally, looking at the code in INetURLObject I noticed this comment:
http://opengrok.libreoffice.org/xref/core/tools/source/fsys/urlobj.cxx#114
and this chunk of code:
http://opengrok.libreoffice.org/xref/core/tools/source/fsys/urlobj.cxx#335
should vnd.sun.star.webdavs be added as well?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
--
Kind Regards,
Giuseppe Castagno
Acca Esse http://www.acca-esse.eu
giuseppe.castagno at acca-esse.eu
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?
On 08/26/2015 02:41 PM, Giuseppe Castagno wrote: 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. So added support for vnd.sun.star.webdavs to LO 5.1 now, https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/5.1oldid=116154#Core. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?
On 08/27/2015 11:45 AM, Stephan Bergmann wrote: On 08/26/2015 02:41 PM, Giuseppe Castagno wrote: 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. So added support for vnd.sun.star.webdavs to LO 5.1 now, https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/5.1oldid=116154#Core. Saw commit [1], probably INetProtocol needs adjusting too. I'll then rebase [2]. After [1] the situation will be: - Linux: - http, https, vnd.sun.star.webdav, vnd.sun.star.webdavs, to WebDAV - dav/davs to GIO - Windows - http, https, vnd.sun.star.webdav, vnd.sun.star.webdavs, to WebDAV - dav/davs not working Don't know on the other platforms. -- Kind Regards, Giuseppe Castagno aka beppec56 Acca Esse http://www.acca-esse.eu giuseppe.castagno at acca-esse.eu [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3de490437df4c9093f32e97fc185066d64c0f46 [2] https://gerrit.libreoffice.org/#/c/17189 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?
On 08/27/2015 12:35 PM, Giuseppe Castagno wrote: On 08/27/2015 11:45 AM, Stephan Bergmann wrote: So added support for vnd.sun.star.webdavs to LO 5.1 now, https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/5.1oldid=116154#Core. Saw commit [1], probably INetProtocol needs adjusting too. Don't think so. Since INetURLObject falls back to INetProtocol::Generic now, there's rarely need these days to keep adding schemes to INetURLObject/INetProtocol. (For example, dav and davs are not there, either.) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?
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. 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. 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. -- Kind Regards, Giuseppe Castagno aka beppec56 Acca Esse http://www.acca-esse.eu giuseppe.castagno at acca-esse.eu [1] https://www.youtube.com/watch?t=23v=dd9mT5WbCyk ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
What autogen.sh for an alternative ContentProvider for dav:// scheme?
Hi all, while I was trying with a fairly current master to open a WebDAV file as: ./soffice dav://192.168.1.80:8080/alfresco/webdav/Sites/davtest/documentLibrary/Lorem_ipsum.odt I got the following warnings: warn:ucb.ucp.gio:17565:1:ucb/source/ucp/gio/gio_content.cxx:400: ignoring GError Not a WebDAV enabled share for dav://192.168.1.80:8080/alfresco/webdav/Sites/davtest/documentLibrary/Lorem_ipsum.odt warn:ucb.ucp.gio:30167:1:ucb/source/ucp/gio/gio_content.cxx:400: ignoring GError Not a WebDAV enabled share for dav://192.168.1.80:8080/alfresco/webdav/Sites/davtest/documentLibrary/Lorem_ipsum.odt warn:unotools.misc:30167:1:unotools/source/misc/mediadescriptor.cxx:688: caught Exception Unable to retrieve value of property 'IsDocument'! while opening dav://192.168.1.80:8080/alfresco/webdav/Sites/davtest/documentLibrary/Lorem_ipsum.odt warn:filter.config:30167:1:filter/source/config/cache/typedetection.cxx:456: caught Exception Could not open stream for dav://192.168.1.80:8080/alfresco/webdav/Sites/davtest/documentLibrary/Lorem_ipsum.odt while querying type of dav://192.168.1.80:8080/alfresco/webdav/Sites/davtest/documentLibrary/Lorem_ipsum.odt warn:fwk.dispatch:30167:1:framework/source/dispatch/loaddispatcher.cxx:132: caught LoadEnvException 0 type detection failed while dispatching dav://192.168.1.80:8080/alfresco/webdav/Sites/davtest/documentLibrary/Lorem_ipsum.odt warn:sal.osl.mutex:30167:1:sal/osl/unx/mutex.cxx:102: pthread_mutex_lock failed: Invalid argument warn:sal.osl.mutex:30167:1:sal/osl/unx/mutex.cxx:139: pthread_mutex_unlock failed: Invalid argument A log on the net told me the OPTIONS method the Alfresco server answered advertised itself as a WebDAV share. The User-Agent on the http transaction was gvfs/1.20.3. master was built with following autogen.sh input: --with-lang='en-US' \ --enable-debug \ --enable-selective-debuginfo=sal/ offapi/ tools/ unotools/ sfx2/ ucbhelper/ ucb/ OTOH, doing the same test on a LO 5.0 production build (5.0.0.5) I got no error and the content provider was the WebDAV ContentProvider, net log confirmed it (User-Agent was LibreOffice). Is this due to a different configuration on LO 5.0.0.5 production build or is there a difference in ucb code? -- Kind Regards, Giuseppe Castagno aka beppec56 Acca Esse http://www.acca-esse.eu giuseppe.castagno at acca-esse.eu ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?
On 08/25/2015 12:07 PM, Giuseppe Castagno wrote: master was built with following autogen.sh input: --with-lang='en-US' \ --enable-debug \ --enable-selective-debuginfo=sal/ offapi/ tools/ unotools/ sfx2/ ucbhelper/ ucb/ OTOH, doing the same test on a LO 5.0 production build (5.0.0.5) I got no error and the content provider was the WebDAV ContentProvider, net log confirmed it (User-Agent was LibreOffice). Is this due to a different configuration on LO 5.0.0.5 production build or is there a difference in ucb code? The reason for this is http://cgit.freedesktop.org/libreoffice/core/commit/?id=51e0d789c344547956764c3b5f0ef5a304f4e0aa rhbz#1134285: Access dav, davs URLs via GVFS (see commit message for details) together with the fact that the TDF LO 5.0 Linux build uses --enable-gnome-vfs (cf. distro-configs/LibreOfficeLinux.conf) while your (master) build defaults to --enable-gio. Punchline: use standard http/https URL schemes instead of non-standard dav/davs ones. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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.) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: What autogen.sh for an alternative ContentProvider for dav:// scheme?
Hi Stephan, On 08/25/2015 01:14 PM, Stephan Bergmann wrote: On 08/25/2015 12:07 PM, Giuseppe Castagno wrote: master was built with following autogen.sh input: ... Is this due to a different configuration on LO 5.0.0.5 production build or is there a difference in ucb code? The reason for this is http://cgit.freedesktop.org/libreoffice/core/commit/?id=51e0d789c344547956764c3b5f0ef5a304f4e0aa rhbz#1134285: Access dav, davs URLs via GVFS (see commit message for details) together with the fact that the TDF LO 5.0 Linux build uses --enable-gnome-vfs (cf. distro-configs/LibreOfficeLinux.conf) while your (master) build defaults to --enable-gio. I see, thanks for the hints. 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. -- Kind Regards, Giuseppe Castagno aka beppec56 Acca Esse http://www.acca-esse.eu giuseppe.castagno at acca-esse.eu [1] https://code.google.com/p/alfresco-share-online-edition-addon/#Registering_the_dav_protocol_in_Linux ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
