Namespace recommendations solicited for libcurl XS interface

Hi,

I'm the current maintainer of the perl XS interface which wraps 'libcurl', the 
library interface of the 'cURL' command line tool. cURL is a "client for 
URL's". (See http://curl.haxx.se for more info).

Curl provides access to a variety of URL schemes (http, https, ftp, dict, 
ldap, file), and includes SSL support, cookie jars, socks, ip-v6 etc. The 
perl XS wrapper provides a more-or-less 1-to-1 mapping of the libcurl API 
into perl, in both an OO and handle/function style.

Following the naming scheme of the standard libcurl 'easy' API, the perl 
module is currently called 'Curl::easy'. Most of the methods map directly 
onto the curl_easy_foo library calls (using the XS PREFIX facility).

Until now, the module has been distributed from the libcurl site, 
http://curl.haxx.se/libcurl/perl . In order to make it easier for end-users 
to install the module via CPAN, I have obtained a PAUSE account and intend to 
distribute new releases via CPAN, in addition to the existing location.

The module naming (chosen before I became maintainer) currently demands a new 
'Curl' top-level namespace, which seems a little greedy for one specific 
library wrapper. I am asking here for advice/recommendations/approval on 
renaming or dual-naming the module, so as to better fit the namespace 
hierarchy, and allow for some future growth in the Curl interface 
functionality.

The basic options, with pros/cons, as I see them:

* Retain Curl::easy name as is.
  + Maintain compatability with all existing code currently using the module.
  + 'Curl' namespace doesn't collide with any existing namespace
  + Immediate distribution of existing module via CPAN
  - Mildly greedy
  - Naming doesn't relate module to function performed, unless you already 
know what curl is. 

* Rename as Net::Curl::easy
  + Unique name for future Net::Curl:: family (Net::Curl::difficult etc..)
  + Better indication of network functionality
  - Need to rename in existing code
  - Breaks existing software unless compatability names also installed
  - Delay in distribution whilst re-work performed

* Rename as HTTP::Curl::easy
  + Follows naming of HTTP::GHTTP, the interface to the gnu http library
  + Indicates web/http-based function of libcurl and interface
   - libcurl does much more than just HTTP, so it's not the best name
   - as above, renaming requires re-work and compatability code

I thought these were the 2 obvious names - please feel free to suggest others.

Whilst considering the naming, note that there are other libcurl interfaces 
under development, which should also be XS wrapped in future:
* The 'multi' interface, which allows multiple non-blocking connections to be 
dealt with simultaneously
* The 'form' interface, which allows HTTP post request bodies to be built up 
from lists of files, fields and in-memory data.
* Perhaps a  'default' or 'handle' interface, which provides a more perl-like 
interface (defaults, I/O settings etc.) compared to the detail-oriented 
'easy' interface. This could be achieved by using Foo::Curl::easy as a 
backend to LWP, as can be done with HTTP::GHTTP

Any change to the existing name would have to be canvassed on the curl/libcurl 
lists before implementation, but I thought it best to start with the 'expert' 
opinions before suggesting any high-impact changes....

Comments please!

Cheers,
Cris Bailiff

• Namespace recommendations solicited for libcurl XS interface by Cris Bailiff
• Re: Namespace recommendations solicited for libcurl XS interface by _brian_d_foy