Hello,
I finished reading S22 (CPAN [DRAFT]). This synopsis is about the
package format, not about the network. I have some comments:
1) Instead of calling the format "JIB", how about "PAR"? It can stand
for Perl ARchive or the recursive PAR ARchive. This is more memorable.
2) S22 proposes the following structure:
p5-Foo-Bar/
lib/
Foo/
Bar.pm
t/
00_load.t
_jib/
META.info
In the rest of this email I will replace "_jib" by "_par".
Now, the first thing I notice is that a single package could hold many
modules. I'm sure this is intentional:
lib/
Canine/
Dog.pm
Feline/
Cat.pm
This gave me another idea: This same format could be used to distribute
*applications*. All we need to do is add an "bin" directory:
p6-Pets-App/
lib/
Canine/
Dog.pm
Feline/
Cat.pm
bin/
Pets.pl
t/
00_load.t
_par/
META.info
So the same package can carry an app, as well as all the modules it
depends on. Even better, the app package can say what Perl modules it
depends on. If my application uses the DBI module, I don't have to
bundle the DBI module with my app. I can simply say that my app depends
on that module and let the package manager take care of it.
This change would make it much easier to distribute Perl apps.
What do you think?
3) Then again, if we are going to allow that, then maybe we also want to
allow a "share" directory:
p6-Pets-App/
lib/
Canine/
Dog.pm
Feline/
Cat.pm
bin/
Pets.pl
share/
pets-icon.png
t/
00_load.t
_par/
META.info
4) Lastly, while we are at it, why don't we add a signature file to the
_par directory?
_par/
META.info
CHECKSUMS.asc
The CHECKSUMS.asc file would contain the SHA1 sums of every file in the
archive except for itself. The file could be GPG-signed with --armor
(.asc extension).
What do you think?
Daniel.
