On Sun, 19 Aug 2018, Sven Schreiber wrote:
Am 14.08.2018 um 19:42 schrieb Allin Cottrell:
> On Tue, 14 Aug 2018, Sven Schreiber wrote:
>
>> 2. Then there are the zip format packages. With the exception of
>> 'Threshold_Panel' and 'dhurdle' (and anything else?), all of
these have
>> PDF help files. My proposal would be to put those pdf files manually into
>> a subdirectory
>>
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/current_fnfiles/unzipped/pdf/ -
>> the package moderators including myself can take care of that I think. And
>> then add a link to current_fnfiles/unzipped/pdf/<pkgname>.pdf to the
>> description field of the package listing. This latter step would involve
>> changing the dynamic web code for SHOW_FUNCS, but not much I guess.
>
> Yes, something like that should work. Also I think the "extract the PDF to
> such-and-such a place" step could be automated (on upload, or probably
> better, on approval).
>
I'd like to move forward with the web links to the respective PDF help files.
I'm not against automation (of course), but as I said I wouldn't mind to
extract and collect the pdf files manually. There isn't such a rapid flow of
new packages, so it's not a problem.
Which variant should it be then, and which sub-directory for the pdf files?
I've reminded myself what the relevant server-side code looks like.
At present we extract the gfn code from a zip package to a temporary
file (to be deleted after use) in the "unzipped" subdirectory of the
current packages directory:
(a) in order to validate a gfn against the DTD on upload;
(b) in response to a request from the web server to list the current
packages (get the author, description, version, date); and
(c) in response to a request from gretl for "info" on a zip package
(right-click menu in packages "on server" window).
It seems to me we could combine this with the PDF business (and into
the bargain cut out some CPU cycles on the server) if we just
extracted both the gfn and the PDF (if present) to the "unzipped"
directory on upload -- not as temporary files but under their own
names, to sit there for the duration (that is, until the zip package
is replaced or retired).
Obviously if we choose this route there's still a need to do the
extraction for the existing zip packages, but that could easily be
accomplished via a shell script on the server.
Allin