[Clipart] Searching and download graphics (2)

[Alan]

To keep the text-based search field updates low, you could organize 
based on month.  All submissions are organized based on date into text 
files organized by month and year.  The search fields and download 
locations could be incorporated into these same text files and easily 
updated.  You would want to put some thought into your search fields, 
because the only time an update would take more time is if you were to 
revise your organizational structure for searches.  You would have to 
update every single text file for each month from the very beginning if 
your were to do this.  Being text files it might not be so bad.  I guess 
it depends on the size of the files.
-------------------
The more we can work with the materials already to hand, probably the
easier.  All of the graphics are already available in small bite-size
png chunks.  I'm not sure how everything is currently set up, but how
about assigning a descriptive permanent name to each png graphic which
then becomes a permanent key.  Perhaps it could be done using a numeric
sequence which is the date and time of submission and/or acceptance into
the database.  This would practically guarantee a completely unique key
for each graphic. That permanent sequence then can be attached to all
kinds of information, including search data (descriptive terms, size,
colors, author, date, whatever).  That sequence could be attached in a
local utility to a download function for png for quick local searches,
but it could also be used to define the svg download.   Your update
function in the  local utility could be used to update a text based file
or files which would update the search fields any time you wanted.
Quick downloads with easy updates to search functionality.  Your png
graphics for local search would also be quick downloads in the small
chunks.  The biggest update of course would be the first update where
the utility and the bulk of the png graphics would be downloaded.  After
that, it would be just very small chunks of updates for search fields
and added png graphics.   When a graphic or graphics is chosen for svg
download, the choices are loaded into a component of the utility which
knows to look for the svg component attached to the permanent key.

This allows complete flexibility with updating the search fields, easy
identification of graphics based on a permanent key, quick updates
locally after initial installation, offloading of search function and
storage to local system, increase of apparent speed in searches due to
local storage, redundancy should the www or the server be slowed down,
and enables the user to use the png graphics should the svg not be
immediately available.

I'm sure I've missed things, and I'm not a programmer (yet), but would
it be possible to set this up?



Thomas Zastrow wrote:
> Alan schrieb:
>> "would be not too difficult"
>>
>> One of the really great things about open source software is that it 
>> truly benefits from ease of use and simplicity.   Highly effective 
>> ideas made as effective/transparent/simple as possible is true 
>> genius.  Open source software caters to this model because there is 
>> nothing to hide and nothing to protect.
>>
>> Be the best you can be, because open source encourages exactly this.
>>
>>
> Alan, I already tried to build PDF-catalogues from the last public 
> provided package 0.18. It wasn't a big problem to write the code: the 
> problem was the realy big amount of cliparts which were already in 
> OCAL. It took too much time and CPU performance for generating PDFs on 
> the fly. And OCAL still grows and grows. So, I think the only way for 
> producing PDFs from OCAL would be an offline way. For doing that, I 
> would need information about the structure of the database, how files 
> are stored and referenced and so on.
>
> Best,
>
> Tom
>
>
>
>
_______________________________________________
clipart mailing list
clipart at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/clipart