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

Response inline below:

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

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


>
> 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?
>

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.

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.

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


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

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.

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.

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.

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


>
> 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?
>

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.

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. :-)

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.

Hope that helps!

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.

Cheers,
-g

Reply via email to