[Clipart] Searching and download graphics

[Alan]

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