RFC: claiming the CPAN root namespace 'EBook'

AZed has asked for the wisdom of the Perl Monks concerning the following question:

I am now probably within a day or two of feeling comfortable uploading the first version of my latest project to CPAN, but I wanted to ask for comment on the namespace before I did so. (This is also going to go out through the PAUSE namespace registration to see if objections result there.)

The project is a base class and an associated command-line tool for generating and manipulating e-books based on the IDPF standards. My working copy is currently using EBook::Tools for the base package name, and 'ebook' for the command-line tool. The name EBook::Tools has already been run by the folks at modules@perl.org and been given blessing, but it was a name really more appropriate to what the project looked like when it began, namely a collection of procedures mostly oriented at helping me do some e-book conversions. I eventually moved the main functionality into an object now capable of substantial examination and modification of the book metadata, and now it seems more appropriate to me to simply name the module 'EBook'.

I've made a snapshot of the pod2html output for both module and tool so people can get a better idea of what the code does. One of the things that I would be working on in upcoming releases would be unpackers for proprietary formats (reimplementing convertlit, mobi2html, and pdbshred), using my base module for cleanup and modification. These would end up going into EBook::Unpack if I claim EBook for the base module.

Is there any major objection to my claiming 'EBook' as my own?

Comment on RFC: claiming the CPAN root namespace 'EBook' Select or Download Code

Replies are listed 'Best First'.
Re: RFC: claiming the CPAN root namespace 'EBook' by moritz (Cardinal) on Oct 07, 2008 at 21:36 UTC
I don't really know if your module is general enough to claim that namespace, especially for such a new module where the interaction with other modules hasn't been thoroughly tested (in terms of API). What about `EBook::IDPF` instead? (The module documentation really need a `SYNOPSIS` section, that's the most important section IMHO).	[reply] [d/l] [select]
Re^2: RFC: claiming the CPAN root namespace 'EBook' by AZed (Monk) on Oct 07, 2008 at 21:52 UTC
If I'm not claiming the root, I'd probably stick with EBook::Tools (and EBook::Tools::Unpack, etc.), since the module doesn't require strict adherence to IDPF specs (there's even special code for handling Mobipocket extensions, for instance) — it only requires that the e-book format be convertible to a superset of one of the IDPF specs internally, and that covers a pretty wide range. EPub books are just IDPF OPF zipped up, Mobipocket is a superset of IDPF OEB 1.2, and Microsoft Lit is pretty much exactly IDPF OEB 1.2 wrapped in a proprietary container. I think the only popular container formats not based on IDPF spec are E-Reader and iSilo (and maybe Plucker for the PalmOS-only crowd), but I should eventually be able to handle imports and exports to iSilo's container format as well (since it is XML), and Plucker is just a HTML parsing toolchain that I can plug in pretty easily at least for generation. Since Mobipocket's PRC is also based on PalmDB, I may even get it to go both ways eventually. It would seem a little odd to me down the line to pick up EBook::IDPF to use an iSiloX ixl file to create a Mobipocket prc, for instance, changing the author name along the way, and I do foresee that kind of functionality. Update: Also, there is a synopsis of sorts, except that it's called 'Example' down at the bottom, and for some reason pod2html didn't link to it properly. I'll switch it up to Synopsis at the top before release.	[reply]