Currently, the $options and $arguments are only used for displaying the
options (eg when you run pluginfo.pl) and for the Librarian Interface to
determine what options are available (it runs pluginfo.pl -xml).
If you do not use these, then you will not be able to use your plugin in
the Librarian Interface.
We have a student here who has been working on changing how the
plugin/classifier option parsing is done. His modifications will be
incorporated into Greenstone after the next release. This modification
gets rid of parseargv and uses the $options and $arguments structures to
determine what options are available.
So anyway, if only you will be using the plugin, and you will be doing
command line building only, then do it anyway you like. But if you are
going to donate your plugin to other people (and the Greenstone project
- yes please) then it would be better to provide the $options and
Hope this helps,
Erik Hetzner wrote:
> Dear GS gurus,
> I am writing a plugin for GS which is much like PagedImagePlug, except
> that it operates on existing PDF files. I have a collection of PDF files
> which have been generated by a OCR company; they include an image of the
> original page with invisible OCRed text on top. The code is separated
> into two modules, one specifically for PDFs and some code to handle all
> sorts of image+text page situations.
> But this is all background. What I'd like to know is, are the rather
> complex $options and $arguments structures which are defined in most
> plugins used? It seems that all plugins use an ad-hoc call to parseargv
> instead. I didn't like parseargv, so I wrote my own little function to
> get the args, but I want to know if this is going to come back to haunt me.
> Many thanks for any help,
> Erik Hetzner
> greenstone-devel mailing list