[Clipart] Document::Manager 0.12

[Jon Phillips]

On Mon, 2005-05-23 at 17:06 -0400, Andrew Archibald wrote:
> 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

Agree. I think you should make some mockup pages in html with our style
before implementing any code. That way we can all look at. I'm having a
hard time following your text and I think the html would be nice to
check out. I think the best way to do this is to just add test pages to
the web cvs module and then we can all add/edit and change, and then
once we get our dream interface, it can all be connected.

I think the easiest way would be to use PHP because the site's interface
is all written that way...I'm not against Python or Perl or anything and
can shift to those languages, but it might be easier for the web
components to stay in a common language. However, Jonadab's scripts use
the shell.php and then do the work in PERL...so maybe that is a good
approach to using another language like Python.

I am encouraging you to contribute how you see fit ;)

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

Sounds good...I think this is important. We need to think about
anonymous and then authenticated users. I think we should continue to
allow anonymous, but some people might want to have an account and then
find out stats. and be able to update their old imagery through a common
username/groupname. However, this functionality would come secondary to
just making a simple interface to DMS.

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

Yes!

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

Sounds good...I recommend to make the mockups and see how the current
site would be affected by these changes. I think basically there should
be a beta interface to DMS for a while, and then we eventually transfer
everything to DMS once the interface has matured.

Please utilize the wiki and the clipart_web cvs module for
progressing...I'm enthused by your outline.

Jon


-- 
Jon Phillips

USA PH 510.499.0894
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)