Re: Commentary on S22 (CPAN [DRAFT])
On Fri, May 29, 2009 at 11:04:38PM +0200, Daniel Carrera wrote: 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. It might make sense to adopt the same naming as .jar and .epub, two very different zipfile-as-container formats. Both use a top-level directory called META-INF. There's no particular technical reason to pick a given name, so going for something that looks familiar to people may be a win. -jesse
Re: Commentary on S22 (CPAN [DRAFT])
jesse wrote: 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. It might make sense to adopt the same naming as .jar and .epub, two very different zipfile-as-container formats. Both use a top-level directory called META-INF. There's no particular technical reason to pick a given name, so going for something that looks familiar to people may be a win. Sounds reasonable. Like you said, there is no strong reason to pick one name or another, so why not pick the name everyone else already uses? Daniel.
Commentary on S22 (CPAN [DRAFT])
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.
Re: Commentary on S22 (CPAN [DRAFT])
Daniel Carrera wrote: 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). To expand on this idea: The current JIB spec includes an Author field in META.info. The spec says: - Author CPAN author id This is perfect. We can offer that people create a CPAN id before distributing apps in PAR format, and upload their GPG public key. Then, when the user installs the app, the installer downloads the public key from CPAN and checks the signature. Of course, we can't mandate that people register with CPAN. This is just a service. So there should be an option to check a signature using a public key you got from elsewhere, or to disable the signature check entirely. Daniel.
