RE: Query on Serf vs Neon - documentation License etc

------=_NextPart_000_1A0A_01D0EFEB.59CB8ED0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Greg,

=20

Many thanks for the info!

=20

I will dig into to it and subscribe to the [email protected] list.

=20

Regards,

=20

John

=20

From: Greg Stein [mailto:[email protected]]=20
Sent: 15 September 2015 08:58
To: [email protected]
Subject: Fwd: [serf-dev] Query on Serf vs Neon - documentation License =
etc

=20

Forwarding: it looks like you won't get my response via either mailing =
list. Please reply to [email protected], and we can cc: you on any =
replies if you note that you're not subscribed.

=20

---------- Forwarded message ----------
From: Greg Stein <[email protected]>
Date: Tue, Sep 15, 2015 at 2:56 AM
Subject: Re: [serf-dev] Query on Serf vs Neon - documentation License =
etc
To: [email protected]



[ our mailing list has moved to [email protected]; bcc: old serf-dev ]

=20

Response inline below:

=20

On Tue, Sep 15, 2015 at 1:08 AM, <[email protected]> wrote:

Hi,

I'm working on a hobby application & I'd to use WebDAV.

I've read Lisa Dusseault's WebDAV book and this pointed me in the =
direction of Neon, which in turn pointed me in the direction of SVN =
which pointed me to Serf.

I'd like to be able to use a fully-featured WebDAV client side and =
possibly server side library.

=20

As I'm sure you've discovered, Serf and Neon are just the client side.

=20


Neon was my initial choice, but since my app uses Apache/MIT licensed =
libraries, I was concerned that the LGPL license of Neon would rule that =
out, but then I noticed that SVN was using an Apache License but was =
using Neon, although use of Neon was then depreciated in favour of Serf.

Some questions to you guys:

1) Is there any documentation for a seasoned C/C++ developer on how to =
use the Serf library. I can't immediately find any. Is it simply a case =
of reading the source code and then looking at the SVN source code to =
see how it drives Serf?

=20

We are lacking that documentation. There are some sample programs in our =
'test' subdirectory, and libsvn_ra_serf, of course. You could also dig =
into Apache OpenOffice, as it uses serf too.

=20

The API is quite different from Neon, as serf is asynchronous. It can =
run multiple connections, pipeline requests, etc. Neon has a higher =
level API, but is synchronous: one API call performs a request and waits =
for the response before returning. In serf, the API is low level, where =
you queue connections and requests, and then "run" the serf context =
repeatedly until completion occurs.

=20

The test programs are good for giving you an idea of the basic pattern =
of operation.

=20


2) How was SVN able to use the Neon library without running into license =
issues?

=20

The larger work (svn) is ALv2-licensed. Components within that larger =
work have different licenses. The svn code files are ALv2, and the bulk =
of its dependencies are permissively-licensed.

=20

Neon is the one non-permissive license, and it was always *optional*. =
The user building svn would choose to incorporate Neon into their local =
build. At that point, they are aware and have accepted the reciprocal =
terms of the LGPL, should they decide to make any changes within Neon, =
for its use within svn.

=20

And to be clear: the licenses have no bearing, unless a (re)distribution =
occurs. Only at that point, do the licenses kick in, and the =
permissive/reciprocal/whatever terms become important.

=20

If you have any further questions in this space, I'd be happy to answer. =
I've been doing licensing for too long :-P

=20


3) How does Serf stack up against Neon for WebDAV support? e.g. how well =
does it interact and adhere to server modules provided by Apache's =
mod_dav and Nginx's equivalent?

=20

serf is a low level library. You queue requests on one or more =
connections, and run them. The requests are built/defined by the =
application code. Thus, it is the app which specifies the PROPPATCH =
method, the HTTP header values, and provides the body of the request. =
serf does not have helper functions (today) to assemble such requests.

=20

Neon has both low and high level interfaces, so it is easier to use. Its =
HTTP capabilities are limited to that single synchronous connection, =
however. Some of us consider its license to be a "mis-feature", which we =
"fixed" when starting serf :-) ... to be clear: many of us are friends =
with Joe Orton. I've known him for 16+ years. Our libraries just have =
different goals, rather than better/worse. :-)

=20

Both libraries are HTTP conformant. In serf's case, the application must =
properly construct DAV requests and must parse the DAV responses. In =
Neon's case, it will help with the request/response handling. Neon is =
certainly compatible with mod_dav (speaking as mod_dav's original =
author). I don't know anything about nginx's DAV support, let alone =
compatibility matrices.

=20

Hope that helps!

=20

Please feel free to subscribe to [email protected] (see =
http://serf.apache.org/contribute), if you decide to use serf and would =
like assistance driving the serf API.

=20

Cheers,

-g

=20

=20


------=_NextPart_000_1A0A_01D0EFEB.59CB8ED0--