Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


On 21.07.2016 08:51, Giuseppe Castagno wrote:

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

that's an awesome idea with a lot of potential for simplifying things,
without introducing new problems since we already bundle curl, but also
quite some work i'm afraid.  maybe the general structure and some code
can be taken from the serf UCP, since it operates at a similar
abstraction level being a HTTP library with no special DAV support?

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>

this would be a useful feature to have, at least as an in-memory cache,
especially for documents that are copy-and-paste from a browser, these
may have lots of linked "button" images that are all identical but we
currently download them N times.

then again, cache invalidation is known to be one of the 2 hard problems
in informatics :)


Context


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.