incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: [DISCUSS] replace neon with libwww (preferred) or libcurl (as 2. choice)
Date Thu, 27 Oct 2011 17:50:03 GMT
Am 10/27/2011 07:01 PM, schrieb Jürgen Schmidt:
> On 10/27/11 5:55 PM, Jürgen Schmidt wrote:
>> Hi,
>>
>> i will continue my evaluation of libwww [1] as a replacement for the
>> neon library that we can't use in the future because of the LGPL license.
>>
>> libwww would be the preferred replacement because of the WebDAV support.
>>
>> "Libwww is a highly modular, general-purpose client side Web API written
>> in C for Unix and Windows (Win32). It's well suited for both small and
>> large applications, like browser/editors, robots, batch tools, etc.
>> Pluggable modules provided with libwww include complete HTTP/1.1 (with
>> caching, pipelining, PUT, POST, Digest Authentication, deflate, etc),
>> MySQL logging, FTP, HTML/4, XML (expat), RDF (SiRPAC), WebDAV, and much
>> more."
>>
>> The license is BSD like and i was already in contact with one of the
>> developers and they would be interested to grant it to Apache if there
>> is enough interest to work on it in the future. It looks like an
>> inactive project but they still receive patches from time to time and it
>> is used in several projects. Well it is a complete implementation of a
>> standard (HTTP 1.1) and besides bugfixes probably not too many things to
>> do. Ok there is still room for improvements in some areas...
>>
>> Having such a HTTP client library written in C might be a good
>> enhancement or extension of an existing Apache project. As far as i know
>> there exists only Java based HTTP client libraries. Or as an own top
>> level project if enough interested people are available.
>>
>> Anyway i will check if we can use it as a replacement for neon and based
>> on the fact that it supports FTP as well, we can perhaps replace libcurl
>> in then future too. But that is not so important at this time.
>>
>> If anybody is interested to help with this effort you are welcome.
>> Beside the reimplementation of the WebDAV UCP (handles all http file
>> access today) we have to integrate libwww in our build env as other
>> external libs on all the supported platforms.
>>
>> If the evaluation fails and we can't use it we can use libcurl for plain
>> http file access. And can later focus on WebDAV by using Apaches own
>> stuff implemented in Java.
>>
>> Any opinions or objections others than Java is bad?
>
> after posting this i found some further info which let me rethinking
> this approach and i would like to ask 2 questions first.
>
> 1. Does anybody already have some experience with libwww?
>
> 2. How important do you think is WebDAV support in the future?
> - Nice to have as we had it before
> - Important because widely used
> - Not so important, we should better focus on CMIS integration
>
> I don't want spent time on the wrong things and libcurl is of course
> widely used, already available in our build env and well accepted. My
> initial approach was perhaps too much focused on not losing WebDAV support.
>>
>> [1] http://www.w3.org/Library/

If WebDAV is not necessary for CMIS implementation, then it is less 
important. The only nice feature I know is that you can load and save 
from network connections (e.g., FTP server). Would be great to keep this 
functionality but I don't know how bad it would be if future releases 
don't support this anymore.

Marcus

Mime
View raw message