Talk:Gallery2:Downloadable Plugins

From Gallery Codex

Format

• You have some references to layouts, which are now themes
• I think that we should require that the self unpacker takes a directory

and fails if one is not provided. No need to have a fallback; we will use it correctly.

• Unpacker should probably do a pre-scan to figure out whether or not any files that it wants to unpack already exist, and let the user say that it's ok to overwrite them.

Package

Variants

1. It's probably easiest if the base version includes the po directory, the GNUmakefile and the strings.raw file.

2. All we need to include here is the test/ subdir

3. include all locale/ and po/ files.

4. This should include locale/xx_XX/ and po/xx_XX.po. Most people won't need the po file, but it's easiest to just send that along also so that they can do i18n maintenance if they want/need to.

Plugin Descriptor

• What purpose does 'group' serve in the header?

The idea was to be able to create a table sorted by groups based only on the header information, but I agree that the group ID is not needed. The group description is enough for that purpose. Jozefs 14:27, 29 Jul 2005 (CEST)

Packages

• To avoid namespace issues, make a unique name for the unpack() function. Otherwise if you try to run two unpackers in the same request, it'll complain about you redefining the unpack() function (not to mention that you might have problems if we're running inside a CMS that defines unpack()
• Make the fopen/print/fclose calls into a function call that's defined once.
• Design it so that it can be included.

<?php
function unpack_1a3c8($outputDir) {
   expand_1a3c8($outputDir, 'module.inc', '.....');
   expand_1a3c8($outputDir, 'classes/class1.class', '.....');
   ...
}

function expand_1a3c8($outputDir, $relativePath, $data) {
   // do unpacking
}

$unpackFunction = "unpack_1a3c8";
?>

So then the caller does:

<?php
  $packedFile = '...';
  include($packedFile);
  $unpackFunction($outputDir);
?>

As I mentioned above, I would not allow a default outputDir. If we need a default later, we can add it.

Repository

• Consider that we may eventually want digital signatures for the packages. Don't do anything about this now, but keep it in mind.
• I assume that the repository tools will be web based?

I should've made that more clear. They're web based, located in lib/tools/repository, and are modeled after lib/test/phpunit. They load the Gallery framework and use it. I'll regularly commit these to gallery-contrib/downloadable-plugins. - Jozefs 14:32, 29 Jul 2005 (CEST)

End-User Administrative Tools

I know this is outdated, but I'll enumerate some things I'd like to see:

• The tool should seek to show only compatible plugins unless the user specifically asks to see everything else.
• The tool should always indicate when there's a newer version of G2 available and link to the download page as well as the upgrading instructions.
• The tool should allow you to upgrade modules that are inactive
• If you download modules that are active, it should seek to leave them active when its done upgrading.
• It should prompt you to create the plugins base dir and chmod it 777 before continuing.

Questions to Think About

• For now the server component doesn't need to be anything special and packageable. We can and should push it into CVS though so that others can install it if they want.
• I'm not worried about frame/icon/color packs for now. We can add that as a variant later if it makes sense. This bears some thought.