Greg,
Many thanks for the info! I will dig into to it and subscribe to the [email protected] list. Regards, John From: Greg Stein [mailto:[email protected]] Sent: 15 September 2015 08:58 To: [email protected] Subject: Fwd: [serf-dev] Query on Serf vs Neon - documentation License etc 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. ---------- 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 ] 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
