[Clipart] upload_svg.cgi and shell.php

[Jonadab the Unsightly One]

Nicu Buculei <nicu at apsro.com> writes:

> we have two pages generated by cgi scripts: one is upload_scg.cgi and
> another is navigate.
> for integration with the website upload_svg.cgi uses the Perl module
> OpenClipart::Web and navigate uses the PHP script shell.php.
  
OpenClipart::Web uses shell.php, but takes care of the details of
retrieving it, so that the calling code doesn't have to mess with
that.  OpenClipart::Web is also used by upload_screenshot.cgi and will
be used also by any other pieces of the site that I write or maintain.
  
> - syncronization: when a change is made in the website layout (header,
> footer, sidebars) it is automatically picked by
> shell.php. OpenClipart::Web should be separately updated in order to
> include it. 

OpenClipart::Web now updates itself from shell.php automatically.

> a symthom is the 'Incoming Clip Art' box from right sidebar: using
> shell.php is live but using OpenClipart:Web it contains an older
> shapshot;

This is for performance reasons.  OpenClipart::Web caches shell.php
because loading it every time was slowing down page loads by more than
an order of magnitude.

The _frequency_ with which the cache is updated is open for debate.
Currently it's set to 1/50th of the time on average.  We probably
should look at the access log and figure out how frequently the
scripts that use it (upload_svg and upload_screenshot) are accessed,
so that we know how often that comes out to.  This is something I've
been meaning to do and just haven't GART yet.

> - less maintenance: 

Irrelevant.  OpenClipart::Web updates its cached copy automatically
from time to time.  No additional maintenance is required.

As an added bonus, if something about shell.php changes, so that
e.g. the output function has to use a different regular expression,
then that only has to be changeed in one module, instead of every
script that uses it.

> using shell.php involves 6 lines of Perl code and 4 lines of PHP
> code and OpenClipart::Web consist of several hundred lines of code
> in itself
  
All OpenClipart::Web does, basically, is use shell.php.

Really, it's not that much code.  "Several hundred lines" makes the
module sound huge, but the functionality that your "six lines of Perl
code" would accomplish is represented by no more than ten lines in
OpenClipart::Web

Most of the "several hundred lines of code" is the cached copy of
shell.php, and that's just data -- I didn't write it by hand, and it
does not have to be maintained.  Most of the rest, as with all decent
code, is documentation (POD) and comments.

The functional part of OpenClipart::Web is about thirty lines.

Ten lines of that is the subroutine that updates the cache.

Another ten lines (the output subroutine) is stuff related to
interpolating the custom content, stuff that would have to go in the
calling code if it weren't done in the module.  This routine is called
with different arguments from multiple different places in each script
that uses it, so inlining it is definitely not a good idea.

The remaining ten lines is about five lines of actual logic, plus
another few lines of incidental stuff like the package declaration and
whatnot.

I could golf down the functional part of OpenClipart::Web to half a
dozen lines, and I could remove all the comments and POD, but I
wouldn't be doing anyone any favours, least of all whoever ends up
maintaining the code after me.  One thing I could do is have it store
the cache externally in a separate file, but that doesn't seem like a
very substantial change of functionality, and it would have an impact
(admittedly, a small one, much smaller than fetching shell.php itself)
on performance.

My real preference would be to do the whole site in Perl (redoing
shell.php as OpenClipart::Shell perhaps) and get rid of the PHP
entirely, but that's because I'm a Perl geek; I suspect the PHP buffs
would complain.

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/