[Clipart] Document::Manager 0.12

[Andrew Archibald]

Bryce Harrington wrote:

>>>>The CGI interface, in theory, should be the easy part, at least to get
>>>>something basic working initially.
>>>
>>>Agreed.  If I put together a really simple proof of concept cgi, would
>>>you be interested in taking that on?
>>
>>Quite possibly.  Although I may be fairly busy in June.  It's also the
>>sort of thing we might be able to share among several people, long term.
> 
> 
> Okay, I started roughing together some code based on CGI::Builder.  I
> can populate it with a few soap calls as examples.  I think it should be
> pretty straightforward to build off of.  What CVS should I check it
> into?

I could write some of the CGIs (if nobody minds they're in Python).  But 
maybe there should first be some discussion about the desired ultimate UI - 
no need to finalize it, but it would be good to plan the right general 
structure.

As I see it, we need:
(1) An upload interface
(2) A search and download interface
(3) A way for "developers" to manipulate the repository

(1) should be a CGI script.  It should accept on SVG file or an archive 
file containing SVG files.  Upon receipt, they should be extracted, parsed, 
thumbnailed, scanned for malware and non-portable SVG, and marked "not yet 
reviewed". A page showing thumbnails and listing keywords for all the 
submitted images should be shown to the user; at the bottom there should be 
a button saying "Yes, I want to release these images, as they appear here, 
as part of OCAL."  Any problem images (no license keyword, 
broken/non-portable SVG, scripts) can be flagged here.  If the user does 
not approve their own upload, we should probably discard the images (in the 
interest of respecting the author's wishes).

(2) should present a search box that searches (at the user's request) some 
or all of: filename, different types of metadata, text inside the SVG file, 
OCAL-internal status (not yet scanned for malware, etc.) It should also 
present a list of "top-level" keywords as clickable links. The result would 
be another search page, with the search narrowed to the results, and with 
thumbnails of a page full of the results. (clicking on a keyword link would 
narrow the images of interest to those containing the keyword or a 
sub-keyword of that keyword: for example, since flags would be tagged as 
"symbol" and "geography"), clicking on the symbol link followed by the 
geography link (in either order) would narrow the results to just images 
matching symbols and geography.

(3) should be done using SOAP so that scripts can be easily written (in any 
language).  A developer wants to de-capitalize all the keywords; they write 
a script that browses all the available keywords and for each capitalized 
one they search for all images matching it and changes it to lower-case 
(incidentally, I do not think this would be a good idea).  A developer 
wants to approve an image that contains script; they run a standard 
scriptlet that does just that.  This obviously requires some sort of 
authentication; the easiest (if SOAP supports this) is to require these 
connections to be from the fdo machine (developers can use SSH port 
forwarding to run programs on their home machines, but anyone with an fdo 
account then gets magic developer powers); better would be to use OpenSSL 
user authentication (as OpenVPN does).  However, an anonymous access to the 
library would be extremely valuable - this would then make writing an OCAL 
browser (possibly with built-in uploading) just a question of using SOAP to 
access the Web version.

Andrew