Re: Top level naming suggestion

2011-01-31 Thread David Nicol
 Before I upload the code (which is already written, for all methods MetaCPAN
 allows, and more) to CPAN and Github, I just wanted to know that taking a
 top-level namespace here makes sense and get any input on it. Here are some
 notes:
 1. It does not use Mechanize, LWP, or anything for which the WWW:: namespace
 would make sense.

naming something after its implementation details doesn't make sense.
Including the name of a framework in the name of a plugin makes sense,
but that's different.

 2. Tiny and concise, as to be an official completely workable API
 implementation (currently using Mouse - or rather, Any::Moose - and
 HTTP::Tiny).
 3. I prefer not to bury this inside a low namespace
 (WebService::PerlRelated::MetaCPAN::API::Implementation::Sawyer).
 4. I've spoken to Olaf Alders from MetaCPAN and he assured me they have no
 problem with the name, and that they would use it themselves once it's out.

how about MetaCPAN::API since that's what it provides? So
MetaCPAN::FAQ and MetaCPAN::Server can be at the same level. But
that's redundant isn't it; if one wants to use MetaCPAN one is going
to need to use the API -- including ::API may be toxic clarity.


Re: Top level naming suggestion

2011-01-31 Thread Sawyer X
On Mon, Jan 31, 2011 at 5:39 PM, David Nicol davidni...@gmail.com wrote:


  2. Tiny and concise, as to be an official completely workable API
  implementation (currently using Mouse - or rather, Any::Moose - and
  HTTP::Tiny).
  3. I prefer not to bury this inside a low namespace
  (WebService::PerlRelated::MetaCPAN::API::Implementation::Sawyer).
  4. I've spoken to Olaf Alders from MetaCPAN and he assured me they have
 no
  problem with the name, and that they would use it themselves once it's
 out.

 how about MetaCPAN::API since that's what it provides?


I thought that was implied by me picking that name, but thanks for
explicitly stating it.


 So
 MetaCPAN::FAQ and MetaCPAN::Server can be at the same level. But
 that's redundant isn't it; if one wants to use MetaCPAN one is going
 to need to use the API -- including ::API may be toxic clarity.


No necessarily. MetaCPAN have written MetaCPAN.pm (not on CPAN yet), which
they use for the maintenance of MetaCPAN, such as DB access, etc.