forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Helena Edelson <>
Subject Re: photogallery plugin thoughts
Date Fri, 06 Jan 2006 15:52:06 GMT

Just wondering since Java was mentioned, will you be coding this in xml 
for Forrest or do you need something in Java for Cocoon?
something using JPEGCodec, JPEGImageEncoder, MediaTracker, Graphics2D, 
Resize, etc?

My experience is that uploading the full images and using software/code 
to generate the thumbnail on the server is memory intensive, although I 
am not familiar with the readers mentioned by Tim. I know of a dll that 
resizes on the server on upload but who runs windoz servers anyway.


philippe perez wrote:

> Hi Tim,
> I read you proposal with a real interest because I have the same 
> feeling a couple of weeks ago.
> (I don't have any skills in Java programming ... ;-) )
> I'm using Forrest Photogallery plugin feature into a personnal 
> genealogical site and I'm
> manipuling a lot a family pictures and/or census scans....
> I spent a lot of time to migrate my previous Forrest v0.6 into 
> Photogallery directories
> and it was a mess to have to generate images three times each.... 
> Apart of that is the
> disk space required according to the resolution used.
> So in my point of view, I would be a great mechanism to only have one 
> original picture
> and Forrest take care of everything for the others 2. So point 2 is my 
> preferred.
> If somebody decides to implement that please let me know where I have 
> to sign up ;-)
> Regards
> Philippe
> Tim Williams wrote:
>>I've looked at the Photogallery plugin and have some changes I'd like
>>to discuss.
>>1) Move from directory to file convention.  I don't particularly care
>>for the whole directory-based convention for the image variations
>>(preview | small | big).  I'd like to just be able to dump a bunch of
>>existing image directories into the gallery and not have to do much
>>work.  (Yeah, I know there's scripting that can do some grunt work
>>here).  I'd like to move the plugin to a filename based approach.  The
>>short version is that each image variation would live in the same
>>directory as the main image file but with an added identifier in the
>>name.  Something like:
>>2) Let cocoon generate these images for us.  I don't like having to
>>pregenerate all of the image variations so I would like cocoon to do
>>it for us. This is pretty simple with the ImageReader but we very
>>quickly run into memory issues.  The only solution to this (besides
>>the obvious boosting maxmem) I can think of is to implement a
>>PersistentImageReader that, once it generates the requested image
>>variation, writes it to disk.  Then, the next time though it only
>>needs to be read from disk.  This means that cocoon needs write
>>permission but it's about the best way I can think to do it.
>>I've actually got #1 working with the plain ImageReader (although it
>>could be static disk-based as well).  I've got #2 mostly working as
>>well but the image writing needs some cleanup.  Anyway, I like where
>>this is going but didn't want to drastically change the current plugin
>>without some discussion.
> -- 
> *
> Philippe PEREZ*
> Partner Support Engineer
> Tél. : +33 1 34 03 17 08
> Fax : +33 1 34 03 17 20
> Port. : +33 6 08 52 82 38
> AIM : pperezfr
> * <>*
> *Sun Microsystems France S.A*
> 13 avenue Morane Saulnier
> 78140 Velizy Villacoublay
> Le site dédié à la formation :
> <>
> Augmentez vos bénéfices.
> Toutes les formations Solaris 10.
> » Enregistrez-vous dès à présent 
> <>
>"Legal Notice
>The information contained in this communication is confidential, is intended only for
the use of the recipient named above, and might be legally privileged.
>If the reader of this message is not the intended recipient, you are hereby notified that
any dissemination, distribution or copying of this communication is strictly prohibited.
>If you have received this communication in error, please resend this communication to
the sender and delete the original transmission or any copy of it."

View raw message