[Clipart] upload_svg.cgi and shell.php

[Jonathan Phillips]

PHP, PERL, etc...diversity is a good thing and lets developers from
different areas participate. Great work on both the PHP and PERL.

Also, could you activate the screenshots page on the website? Its ready
to go right?

Answers to things below:

On Thu, 2004-09-23 at 00:45, Jonadab the Unsightly One wrote:
> 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.

Cool to develop solid modules...

>   
> > - 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.
> 
Great!

> > 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.
> 
Good again...

> > 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.

GO with Darwin and favor diversity ;)


-- 
Jon Phillips

KOREA.PH.010.3140.7483
USA.PH.858.361.2811
jon at rejon.org
http://www.rejon.org

Inkscape (http://inkscape.org)
Open Clip Art Library (www.openclipart.org)
CVS Book (http://cvsbook.ucsd.edu/)
Scale Journal (http://scale.ucsd.edu/)