Hi all,
I've been working on the WebDAV ucb provider in the last months, here I
try to describe a few ideas on WebDAV future work, the short topic list:
1) Add OPTIONS method,
2) Unit checks for neon
3) About serf
4) Curl for WebDAV as well?
5) A very small cache implementation
6) Mimicking MSO way of dealing with URL (Windows platform only).
expanded in the following rows.
1) Add OPTIONS method
==================
For OPTIONS method specification, please see:
<https://tools.ietf.org/html/rfc7231#section-4.3.7>
for general details.
<https://tools.ietf.org/html/rfc4918>
where the use of OPTIONS method is detailed for WebDAV.
The reason to implement this method, is to better detect if a URL
resource is a simple Web resource or if it's WebDAV. In this latter case
detect what methods it supports and what DAV class or classes it implements.
In case of Web accessing (that is, not WebDAV) It should enhance a
little the performance, by removing the bunch of PROPFIND method LO
sends on Web resource.
I've been working on this for a few months now, it seems to works well,
I think it's ripe for inclusion in main codebase.
2) Unit tests for neon
=============================
following a suggestion from mail on dev list:
<http://nabble.documentfoundation.org/WebDAV-provider-tests-how-about-interacting-with-a-server-tp4173184p4173352.html>
I had a look at the way a test with a similar aim was implement in
libcims, which uses libcurl.
In libcmis a libcurl fake code was written, only a handful of functions
were needed.
The same method could be used with neon, but I need to rewrite a bunch
of functions to emulate the way neon works, something I don't have time
ATM. Besides, topic 4) below is probably the way to go, but the longest...
3) About serf
=============
I discussed about serf in an old mail thread:
<http://nabble.documentfoundation.org/Build-WebDAV-neon-serf-differences-among-the-two-tp4157134.html>
AFAIK my serf observations there still stand, please read the thread
there if you are interested on this topic.
Current downloadable version is here:
<https://serf.apache.org/download>
version is 1.3.8.
I don't think it's a good idea change from neon to serf:
pros:
- a more permissive license,
- more simple than neon
- the 'junction code' in LO was already written, though some update is
needed to add what I did on neon counterpart
cons (wrt serf 1.3.8):
- needs scons to compile, sconc doesn’t seem to be used in LO build
- not sure if it handles Windows NTLM authentication under Linux (neon
does), serf 1.3.8 supports NTLM authentication in Windows
- links to a couple of library not used elsewhere
- uses only OpenSSL as crypto library, not big a problem in itself, but
NSS would be preferable.
of course, that is just what I think.
4) Curl for WebDAV as well?
===========================
4) the idea came up reading
<http://nabble.documentfoundation.org/Build-WebDAV-neon-serf-differences-among-the-two-tp4157134p4157624.html>.
I'd like to spend some time to see about libcurl doing the work neon
does, by implementing first OPTIONS, HEAD GET methods, the one needed
for standard web access.
The (very brave and challenging) idea is to substitute neon with libcurl
in the future.
From LO code POV, libcurl is very similar to serf: an external
library that performs the bare needs of 'http://' protocol.
So some idea on how to use libcurl stem out from both the serf software
connection structure in ucb provider, and the way libcurl is used in
libcmis.
Obviously, in this case, the unit tests for WebDAV will follow the road
used in libcmis for libcurl.
Need some advice on this: is it worth the effort? In terms of license,
other libs libcurl uses, etc...
I think that implementing the basic methods for standard Web reading
(OPTIONS, HEAD, GET) will give me an idea of what I'm facing.
If libcurl works as I expect, we will get rid of both neon and serf.
What do you think?
As a reference, libcurl site: <https://curl.haxx.se/>.
5) A very small cache implementation
==================================
A little Web cache should be implemented, limited to cache GET methods
results for Web resources only.
For the time being this is just an idea I'm playing with...
RFC7234 defines http cache behaviour:
<https://tools.ietf.org/html/rfc7234>
6) Mimicking MSO way of dealing with URL (Windows platforms only)
================================================================
in Win only: implement detection of http/s links as MSO does like
explained here:
<https://blogs.msdn.microsoft.com/brian_jones/2006/02/17/how-office-detects-that-a-unc-path-is-really-a-webdav-url>
Judging from logs I saw a few months back on a customer of mine Windows
installation, that's still the way MSO works.
If implemented, best enable it by some advance configuration flag,
defaulting to disabled, in order to not disrupt current LO uses.
This topic, like 5) above, is just an idea I'm playing with...
Thoughts are welcome.
--
Kind Regards,
Giuseppe Castagno aka beppec56
Acca Esse http://www.acca-esse.eu
giuseppe.castagno at acca-esse.eu
Context
- WebDAV ucb provider: neon, serf, ideas... · Giuseppe Castagno
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.