[Clipart] SVG::Metadata Release 0.08

[Jonadab the Unsightly One]

Bryce Harrington <bryce at bryceharrington.com> writes:

>> ... and I'd still get valid RDF here, which instead of being put
>> into the SVG could be written alongside the .png or whatever with
>> an .rdf extension, yes?
>
> Correct.  Although note that it's wrapped in <metadata> </metadata>,
> which is SVG, not RDF.  We'd want to strip that out, probably.

Ah, an easy adjustment to make.  Next time I make any changes to the
upload script I'll do that while I'm at it.

> Cool.  In the future I may work on better doc management backend
> thingee for us, if I have time, to handle version control, filename
> conflicts, etc.  For now, this approach sounds good.

There shouldn't be any filename conflicts with the upload script now:

    my $t = lc $meta->title() . "_";
    $t =~ s/[^A-Za-z0-9.-]+/_/g;
    my $n = "01"; { # This way we get dolphin_01.svg, dolphin_02.svg, &c.
      ++$n while (-e catfile($CONFIG{destination_directory}, "$t$n.svg") or
                  -e catfile($CONFIG{destination_directory}, "$t$n.rdf"));
      $t .= $n;
    }

In fact, if there's already a foo_01.png and somebody uploads an SVG
called foo, it'll be foo_02.svg.  

That assumes all the images are still in the destination area,
though.

One thing it doesn't care for is obsoleting old versions of the same
image.  That will probably need human intervention, although a script
could go through and make a list of files with very similar metadata
for someone to check.  In some cases we might want to keep both
versions, if the revision seems more like a horizontal change than
finishing something that was previously imcomplete.  That's the sort
of thing a script can't decide (though it might be possible to let the
author specify it on upload).

> Then I'll generalize the upload script to handle types other than SVG

I _think_ I have this checked in now, if I understand how CVS works,
but the new version is probably not live on the site yet.

Also, it now uses a library, OpenClipart::Web, which is also checked
in as OpenClipart-Web.pm and needs to go in one of those use lib
directories.  (Also, it relies on LWP::Simple, so that will be needed
if it's not there already.)  Other Perl scripts for the site can use
this too if desired; it attempts to load shell.php (or falls back to a
static copy taken from it) and supplies an output routine that takes
named arguments for content (required), title (optional, defaults to
whatever shell.php says), and optionally a cookie header (actually,
any optional HTTP header can be put there).  (Other named arguments
can be added to it if desired later, e.g. for adding a login box to
the menu if the user isn't logged in, if we later have pages that need
that sort of thing.)  So the upshot of this is that the upload script
should now look like the rest of the site, or at least it should look
a lot like shell.php

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