You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Tim Williams <wi...@gmail.com> on 2006/01/06 14:06:53 UTC
photogallery plugin thoughts
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:
IMG001.jpg
IMG001.thumb.jpg
IMG001.small.jpg
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.
WDYT?
--tim
Re: upgrading Forrest's Cocoon (Was: photogallery plugin thoughts)
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
> David Crossley wrote:
> > There are two separate issues here.
> >
> > One is to upgrade Forrest version of Cocoon and blocks
> > to a recent version of Ccooon-2.2 i.e. their trunk,
> > and also to include the ImageReader block.
> > See below.
> >
> > The other is that you want to make a change to
> > the ImageReader block of Cocoon. For that you need
> > to commit the changes to Cocoon trunk. As a Forrest
> > committer you can do that. If you think that it needs
> > discussion then do so on cocoon-dev. Otherwise send
> > a patch to their Jira (don't jold your breath on getting
> > it applied).
>
> I've misled you I think. I am not wanting to modify the Cocoon
> ImageReader block. I've implemented a new
> org.apache.forrest.readers.PersistentImageReader that currently
> inherits from ResourceReader but will eventually inherit from
> ImageReader. No changes to the actual Cocoon code necessary -- it'll
> be our own reader.
Ah then we are on completely different wavelengths.
I just assumed that you were using Cocoon's facilities
and were going to enhance it.
Then we need to talk about this. There is a good reason
for Forrest not having much Java code. Where possible
we use Cocoon blocks and help to keep them maintained.
I don't know where we draw the line between developing
our own code and using/ehancing Cocoon's.
-David
> > Tim Williams wrote:
> > > David Crossley wrote:
> > > >
> > > > So this would require adding the cocoon-imagereader-block
> > > > to Forrest. Are you happy with doing Forrest's Cocoon
> > > > upgrade process? I will do it if you are not comfortable.
> > >
> > > Yeah for now I'm inheriting directly from the ResourceReader so that I
> > > can get it done -- just copied the code of the ImageReader. I don't
> > > know how to upgrade Cocoon yet.
> >
> > There is the procedure described in etc/cocoon_upgrade/README.txt
> >
> > > I wouldn't mind trying but since I've
> > > already svn up'd my cocoon trunk with the new flattened structure it'd
> > > have the added complexity of trying to do it a against a specific
> > > version and I think that's not a good idea for my first time. If you
> > > have time, please do.
> >
> > That is normally easy.
> >
> > Update your Cocoon svn backwards [*] ...
> > svn up -r 366396
> >
> > Do the upgrade. Follow etc/cocoon_upgrade/README.txt
> > Granted this is a bit frightening the first time,
> > but need to start sometime.
> >
> > When all finished, then restore Cocoon to head ...
> > svn up -r HEAD
> >
> > However that is not going to work, because you need to
> > add new functionality to Cocoon. We can maybe upgrade
> > the Cocoon core and blocks now. And then when you are
> > ready, we will upgrade just the Imagereader block.
> >
> > [*] Finding a good working version of Cocoon is difficult.
> > Starting at r358825 Giacomo upgraded to jetty-5.1.8 so we
> > will need to upgrade upgrade our Jetty too.
> >
> > If no-one beats me to it then i will upgrade our Cocoon
> > to r385824 (as long as it works) and we can upgrade just
> > the imagereader block later.
> >
> > After that we are going to need to amend our Cocoon
> > upgrade procedure to use their new Maven2 based build.
> >
> > -David
>
> Thanks David, I'm about to take off for a month for work. I doubt
> I'll get to do much more than follow mail during that time, though
> I'll try to clean this photo-gallery stuff up. I've got most
> everything working except the "main" gallery page -- having an odd
> transformer issue there that I'm sure is something embarrassingly
> simple.
>
> --tim
Re: upgrading Forrest's Cocoon (Was: photogallery plugin thoughts)
Posted by Tim Williams <wi...@gmail.com>.
On 1/8/06, David Crossley <cr...@apache.org> wrote:
> There are two separate issues here.
>
> One is to upgrade Forrest version of Cocoon and blocks
> to a recent version of Ccooon-2.2 i.e. their trunk,
> and also to include the ImageReader block.
> See below.
>
> The other is that you want to make a change to
> the ImageReader block of Cocoon. For that you need
> to commit the changes to Cocoon trunk. As a Forrest
> committer you can do that. If you think that it needs
> discussion then do so on cocoon-dev. Otherwise send
> a patch to their Jira (don't jold your breath on getting
> it applied).
I've misled you I think. I am not wanting to modify the Cocoon
ImageReader block. I've implemented a new
org.apache.forrest.readers.PersistentImageReader that currently
inherits from ResourceReader but will eventually inherit from
ImageReader. No changes to the actual Cocoon code necessary -- it'll
be our own reader.
> Tim Williams wrote:
> > David Crossley wrote:
> > >
> > > So this would require adding the cocoon-imagereader-block
> > > to Forrest. Are you happy with doing Forrest's Cocoon
> > > upgrade process? I will do it if you are not comfortable.
> >
> > Yeah for now I'm inheriting directly from the ResourceReader so that I
> > can get it done -- just copied the code of the ImageReader. I don't
> > know how to upgrade Cocoon yet.
>
> There is the procedure described in etc/cocoon_upgrade/README.txt
>
> > I wouldn't mind trying but since I've
> > already svn up'd my cocoon trunk with the new flattened structure it'd
> > have the added complexity of trying to do it a against a specific
> > version and I think that's not a good idea for my first time. If you
> > have time, please do.
>
> That is normally easy.
>
> Update your Cocoon svn backwards [*] ...
> svn up -r 366396
>
> Do the upgrade. Follow etc/cocoon_upgrade/README.txt
> Granted this is a bit frightening the first time,
> but need to start sometime.
>
> When all finished, then restore Cocoon to head ...
> svn up -r HEAD
>
> However that is not going to work, because you need to
> add new functionality to Cocoon. We can maybe upgrade
> the Cocoon core and blocks now. And then when you are
> ready, we will upgrade just the Imagereader block.
>
> [*] Finding a good working version of Cocoon is difficult.
> Starting at r358825 Giacomo upgraded to jetty-5.1.8 so we
> will need to upgrade upgrade our Jetty too.
>
> If no-one beats me to it then i will upgrade our Cocoon
> to r385824 (as long as it works) and we can upgrade just
> the imagereader block later.
>
> After that we are going to need to amend our Cocoon
> upgrade procedure to use their new Maven2 based build.
>
> -David
Thanks David, I'm about to take off for a month for work. I doubt
I'll get to do much more than follow mail during that time, though
I'll try to clean this photo-gallery stuff up. I've got most
everything working except the "main" gallery page -- having an odd
transformer issue there that I'm sure is something embarrassingly
simple.
--tim
upgrading Forrest's Cocoon (Was: photogallery plugin thoughts)
Posted by David Crossley <cr...@apache.org>.
There are two separate issues here.
One is to upgrade Forrest version of Cocoon and blocks
to a recent version of Ccooon-2.2 i.e. their trunk,
and also to include the ImageReader block.
See below.
The other is that you want to make a change to
the ImageReader block of Cocoon. For that you need
to commit the changes to Cocoon trunk. As a Forrest
committer you can do that. If you think that it needs
discussion then do so on cocoon-dev. Otherwise send
a patch to their Jira (don't jold your breath on getting
it applied).
Tim Williams wrote:
> David Crossley wrote:
> >
> > So this would require adding the cocoon-imagereader-block
> > to Forrest. Are you happy with doing Forrest's Cocoon
> > upgrade process? I will do it if you are not comfortable.
>
> Yeah for now I'm inheriting directly from the ResourceReader so that I
> can get it done -- just copied the code of the ImageReader. I don't
> know how to upgrade Cocoon yet.
There is the procedure described in etc/cocoon_upgrade/README.txt
> I wouldn't mind trying but since I've
> already svn up'd my cocoon trunk with the new flattened structure it'd
> have the added complexity of trying to do it a against a specific
> version and I think that's not a good idea for my first time. If you
> have time, please do.
That is normally easy.
Update your Cocoon svn backwards [*] ...
svn up -r 366396
Do the upgrade. Follow etc/cocoon_upgrade/README.txt
Granted this is a bit frightening the first time,
but need to start sometime.
When all finished, then restore Cocoon to head ...
svn up -r HEAD
However that is not going to work, because you need to
add new functionality to Cocoon. We can maybe upgrade
the Cocoon core and blocks now. And then when you are
ready, we will upgrade just the Imagereader block.
[*] Finding a good working version of Cocoon is difficult.
Starting at r358825 Giacomo upgraded to jetty-5.1.8 so we
will need to upgrade upgrade our Jetty too.
If no-one beats me to it then i will upgrade our Cocoon
to r385824 (as long as it works) and we can upgrade just
the imagereader block later.
After that we are going to need to amend our Cocoon
upgrade procedure to use their new Maven2 based build.
-David
Re: photogallery plugin thoughts
Posted by Tim Williams <wi...@gmail.com>.
On 1/7/06, David Crossley <cr...@apache.org> wrote:
> Tim Williams wrote:
> >
> > Thanks David,
> > That patch appears to expand the image handling capabilities -- which
> > is cool -- but what I'm wanting is simply to write the image variants
> > to disk. I've pretty much got it working but since it's a pretty huge
> > change I want to make sure it's cool with everyone first. Right now,
> > each variant (small, preview, and big) is created in it's own
> > directory manually by the forrest user. What I want is to just be
> > able to drag a bunch of my photo directories into the gallery and have
> > those variants generated by Cocoon automatically -- when I implemented
> > it I also made the change of being filename-based instead of directory
> > based. This works fairly well though as you might imagine the first
> > time through it's still memory intensive too.
> >
> > I also eventually want to make an additional change in behavior. The
> > gallery\ directory will be seen as the root gallery. Any subdirectory
> > of that one can have a gallery.meta file that describes the gallery
> > and also may contain sub-galleries itself.
>
> I for one, am very happy that you make those changes.
> This would certainly change that plugin's version number
> since it is different behaviour.
>
> So this would require adding the cocoon-imagereader-block
> to Forrest. Are you happy with doing Forrest's Cocoon
> upgrade process? I will do it if you are not comfortable.
Yeah for now I'm inheriting directly from the ResourceReader so that I
can get it done -- just copied the code of the ImageReader. I don't
know how to upgrade Cocoon yet. I wouldn't mind trying but since I've
already svn up'd my cocoon trunk with the new flattened structure it'd
have the added complexity of trying to do it a against a specific
version and I think that's not a good idea for my first time. If you
have time, please do.
--tim
Re: photogallery plugin thoughts
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >
> >So this would require adding the cocoon-imagereader-block
> >to Forrest. Are you happy with doing Forrest's Cocoon
> >upgrade process? I will do it if you are not comfortable.
>
> Do not add the block to Cocoon. Add it to the rel;vant jars to the
> plugin lib - no need to rebuild Forrests Cocoon.
I see that all three of us are on different tracks.
Originally i confused things by assuming that Tim
was using the existing image handling capability
in Cocoon, i.e. its Imagereader Block. He is not.
I now presume that Tim has his own Java source code
at the Gallery plugin.
See the other branch of this plugin discussion thread.
> (caveat: this only works if there are no xconf changes in the block,
> although it should be possible to make the plugin system work even in
> this instance - we'd need to discuss how, I've tried a few methods in
> the past)
Fantastic. We need to document that. It sounds like
a very easy way to add Cocoon functionality.
Supposedly if it is common functionality then it goes
in lib/core
-David
Re: photogallery plugin thoughts
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Tim Williams wrote:
>
>>Thanks David,
>>That patch appears to expand the image handling capabilities -- which
>>is cool -- but what I'm wanting is simply to write the image variants
>>to disk. I've pretty much got it working but since it's a pretty huge
>>change I want to make sure it's cool with everyone first. Right now,
>>each variant (small, preview, and big) is created in it's own
>>directory manually by the forrest user. What I want is to just be
>>able to drag a bunch of my photo directories into the gallery and have
>>those variants generated by Cocoon automatically -- when I implemented
>>it I also made the change of being filename-based instead of directory
>>based. This works fairly well though as you might imagine the first
>>time through it's still memory intensive too.
>>
>>I also eventually want to make an additional change in behavior. The
>>gallery\ directory will be seen as the root gallery. Any subdirectory
>>of that one can have a gallery.meta file that describes the gallery
>>and also may contain sub-galleries itself.
>
>
> I for one, am very happy that you make those changes.
> This would certainly change that plugin's version number
> since it is different behaviour.
+1
> So this would require adding the cocoon-imagereader-block
> to Forrest. Are you happy with doing Forrest's Cocoon
> upgrade process? I will do it if you are not comfortable.
Do not add the block to Cocoon. Add it to the rel;vant jars to the
plugin lib - no need to rebuild Forrests Cocoon.
(caveat: this only works if there are no xconf changes in the block,
although it should be possible to make the plugin system work even in
this instance - we'd need to discuss how, I've tried a few methods in
the past)
Ross
Re: photogallery plugin thoughts
Posted by Thorsten Scherler <th...@apache.org>.
El sáb, 07-01-2006 a las 17:34 +1100, David Crossley escribió:
> Tim Williams wrote:
> >
> > Thanks David,
> > That patch appears to expand the image handling capabilities -- which
> > is cool -- but what I'm wanting is simply to write the image variants
> > to disk. I've pretty much got it working but since it's a pretty huge
> > change I want to make sure it's cool with everyone first. Right now,
> > each variant (small, preview, and big) is created in it's own
> > directory manually by the forrest user. What I want is to just be
> > able to drag a bunch of my photo directories into the gallery and have
> > those variants generated by Cocoon automatically -- when I implemented
> > it I also made the change of being filename-based instead of directory
> > based. This works fairly well though as you might imagine the first
> > time through it's still memory intensive too.
> >
> > I also eventually want to make an additional change in behavior. The
> > gallery\ directory will be seen as the root gallery. Any subdirectory
> > of that one can have a gallery.meta file that describes the gallery
> > and also may contain sub-galleries itself.
>
> I for one, am very happy that you make those changes.
> This would certainly change that plugin's version number
> since it is different behaviour.
>
Yeah, please Tim, go ahead. You are trusted here and your proposal looks
very useful.
Thanks for this enhancement.
salu2
> So this would require adding the cocoon-imagereader-block
> to Forrest. Are you happy with doing Forrest's Cocoon
> upgrade process? I will do it if you are not comfortable.
>
> It would be good to do that soon anyway because
> Cocoon are starting to make some more radical changes
> to the build process. A good svn version would be 366397
> which is just befaore Jorg added the tag: trunk_before_flattening
> as part of the Maven2 setup for Cocoon.
>
> -David
>
> > Also, if there happens to be any graphically-gifted folks listening
> > this gallery could use your help because it is pretty rough looking as
> > is. My thought is that to improve it visually we may want to just
> > wait until we can move it to views so that we can use *.fv files as
> > sort of the "Album Layout".
> >
> > --tim
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: photogallery plugin thoughts
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
>
> Thanks David,
> That patch appears to expand the image handling capabilities -- which
> is cool -- but what I'm wanting is simply to write the image variants
> to disk. I've pretty much got it working but since it's a pretty huge
> change I want to make sure it's cool with everyone first. Right now,
> each variant (small, preview, and big) is created in it's own
> directory manually by the forrest user. What I want is to just be
> able to drag a bunch of my photo directories into the gallery and have
> those variants generated by Cocoon automatically -- when I implemented
> it I also made the change of being filename-based instead of directory
> based. This works fairly well though as you might imagine the first
> time through it's still memory intensive too.
>
> I also eventually want to make an additional change in behavior. The
> gallery\ directory will be seen as the root gallery. Any subdirectory
> of that one can have a gallery.meta file that describes the gallery
> and also may contain sub-galleries itself.
I for one, am very happy that you make those changes.
This would certainly change that plugin's version number
since it is different behaviour.
So this would require adding the cocoon-imagereader-block
to Forrest. Are you happy with doing Forrest's Cocoon
upgrade process? I will do it if you are not comfortable.
It would be good to do that soon anyway because
Cocoon are starting to make some more radical changes
to the build process. A good svn version would be 366397
which is just befaore Jorg added the tag: trunk_before_flattening
as part of the Maven2 setup for Cocoon.
-David
> Also, if there happens to be any graphically-gifted folks listening
> this gallery could use your help because it is pretty rough looking as
> is. My thought is that to improve it visually we may want to just
> wait until we can move it to views so that we can use *.fv files as
> sort of the "Album Layout".
>
> --tim
Re: photogallery plugin thoughts
Posted by Tim Williams <wi...@gmail.com>.
On 1/6/06, David Crossley <cr...@apache.org> wrote:
> Tim Williams wrote:
> > Helena Edelson wrote:
> > >
> > > 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.
>
> Helena, Cocoon already has various compoments for
> handling images. See some basic demos here ...
> http://cocoon.zones.apache.org/demos/release/samples/imagereader/
>
> Tim, there is a patch for a new "imageop" block
> sitting in Cocoon Jira which might be of interest.
> http://issues.apache.org/jira/browse/COCOON-1301
>
> -David
Thanks David,
That patch appears to expand the image handling capabilities -- which
is cool -- but what I'm wanting is simply to write the image variants
to disk. I've pretty much got it working but since it's a pretty huge
change I want to make sure it's cool with everyone first. Right now,
each variant (small, preview, and big) is created in it's own
directory manually by the forrest user. What I want is to just be
able to drag a bunch of my photo directories into the gallery and have
those variants generated by Cocoon automatically -- when I implemented
it I also made the change of being filename-based instead of directory
based. This works fairly well though as you might imagine the first
time through it's still memory intensive too.
I also eventually want to make an additional change in behavior. The
gallery\ directory will be seen as the root gallery. Any subdirectory
of that one can have a gallery.meta file that describes the gallery
and also may contain sub-galleries itself.
Also, if there happens to be any graphically-gifted folks listening
this gallery could use your help because it is pretty rough looking as
is. My thought is that to improve it visually we may want to just
wait until we can move it to views so that we can use *.fv files as
sort of the "Album Layout".
--tim
Re: photogallery plugin thoughts
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
> Helena Edelson wrote:
> >
> > 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.
Helena, Cocoon already has various compoments for
handling images. See some basic demos here ...
http://cocoon.zones.apache.org/demos/release/samples/imagereader/
Tim, there is a patch for a new "imageop" block
sitting in Cocoon Jira which might be of interest.
http://issues.apache.org/jira/browse/COCOON-1301
-David
> Hi Helena,
> Yeah, I was talking about extending the ImageReader, which already
> handles the resizing, to just write the newly resized image to disk.
> I want this because of the memory intensiveness you've mentioned. It
> turns it into essentially a one-time (hopefully non-cached) cost, then
> subsequent requests are read straight from disk instead of resizing
> yet again. I think this is a reasonable medium between pre-generating
> everything and dynamically generating everything.
> --tim
Re: photogallery plugin thoughts
Posted by Tim Williams <wi...@gmail.com>.
On 1/6/06, Helena Edelson <he...@greenjaguar.com> wrote:
> Hi,
>
> 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.
>
> Helena
Hi Helena,
Yeah, I was talking about extending the ImageReader, which already
handles the resizing, to just write the newly resized image to disk.
I want this because of the memory intensiveness you've mentioned. It
turns it into essentially a one-time (hopefully non-cached) cost, then
subsequent requests are read straight from disk instead of resizing
yet again. I think this is a reasonable medium between pre-generating
everything and dynamically generating everything.
--tim
Re: photogallery plugin thoughts
Posted by Helena Edelson <he...@greenjaguar.com>.
Hi,
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.
Helena
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:
>>IMG001.jpg
>>IMG001.thumb.jpg
>>IMG001.small.jpg
>>
>>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.
>>
>>WDYT?
>>--tim
>>
>>
>
> --
> *
> 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
>
> *philippe.perez@sun.com <ma...@sun.com>*
>
>
> *Sun Microsystems France S.A*
> 13 avenue Morane Saulnier
> 78140 Velizy Villacoublay
>
> Le site dédié à la formation :
> http://fr.sun.com/formation
>
>
> <https://www.suntrainingcatalogue.com/eduserv/client/cmsearch.do?catId=2021&l=fr_FR>
>
> Augmentez vos bénéfices.
> Toutes les formations Solaris 10.
> » Enregistrez-vous dès à présent
> <https://www.suntrainingcatalogue.com/eduserv/client/cmsearch.do?catId=2021&l=fr_FR>
>
>"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."
>
>
>
Re: photogallery plugin thoughts
Posted by Tim Williams <wi...@gmail.com>.
Philippe,
Can you please send all mailing list email in *plain text*? HTML
isn't very mailing list or mailing archive friendly.
Thanks,
--tim
On 1/6/06, philippe perez <Ph...@sun.com> 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:
> IMG001.jpg
> IMG001.thumb.jpg
> IMG001.small.jpg
>
> 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.
>
> WDYT?
> --tim
>
>
>
> --
>
>
> 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
>
> philippe.perez@sun.com
>
>
> Sun Microsystems France S.A
> 13 avenue Morane Saulnier
> 78140 Velizy Villacoublay
>
> Le site dédié à la formation :
> http://fr.sun.com/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."
>
>
>