Hi Geert,
Thanks for the info/explanation/thoughts/analysis! :)
I think the heart of my question is really a question about the
performance of java.awt.Image. :) If the performance (speed, memory) of
java.awt.Image is poor, then that creates a bottleneck in transforming
images and loading them (and their properties) into the database. So,
abstracting to allow a drop-in representation or library seems logical
and an additional advantage. :) However, "don't guess, measure", eh? :)
My specific task is that I'm building a photo gallery app, and I want to
generate 3 (maybe more) versions of an uploaded file. Since there could
potentially be a lot of files uploaded, it would be nice to have "low"
memory and CPU usage.
Image transform-wise, I've run into a situation (twice now) where I set
a 'width' or 'height' value, but the orientation of some of the images
is opposite which causes it to be scaled incorrectly (i.e. both
1200x1600 images and 1600x1200 images should use the same scaling ratio
but simply setting a width or height doesn't give this result), so I
created a transformer which uses attributes 'short-edge-length' and
'long-edge-length', which does just what I want. Yay! :)
Before I go on and talk about RIFE, I'll say that I'm still a little
fuzzy on the workflow for how an image (file) goes from the temporary
upload directory through the transformers, validator(s) and into the
database.
MimeType: Yes, making the constructor public would allow additional
MimeTypes. Would it also allow overriding the static MimeTypes? Good
thing or bad thing since they would need to be changed before
DatabaseImageStore is instantiated? Would a Participant be able to
handle this, like the ResourceFinder mechanism?
DatabaseImageStore: The only thing here that is obviously image specific
is getContentForHtml(), and that's not image type specific, so pulling
the list of MimeTypes from something that could be overridden seems
possible, though I don't have any quick and elegant ideas about how to
do it either. BTW -- it seems weird to me that getContentForHtml() is
in this class. I suspect I keep think of 'Store' as a verb when it's
really a noun. :)
Other notes, and ideas...
In looking at ImageFormatter, the scaling feature (setting the
width/height) seems like it should really be extracted as a separate
content transformer. Conversion from various formats to jpg should also
be considered transforms (a single 'jumbo' converter transformer could
be used). This leaves the storage mechanism as a validator ("Is what
I'm getting an actual jpeg?") and property extractor (width, height,
whatever you like). (Maybe property extractor should be considered a
type of transformer too? But, leave that question for later.)
I think this approach has a couple advantages. The conversion from
arbitrary formats becomes explicit which allows the user the option to
reject non-jpeg files (such as a case where conversion could introduce
artifacts and so you want to enforce/provide a strict
garbage-in-garbage-out behavior).
Another aspect is that it allows for lightweight analysis tools. A
shortcut validator (again, this could be a decision by the user) could
potentially just analyze the header and extract properties from it which
makes it very low impact on cpu and memory.
Maybe a convenient addition to the ConstrainedProperty api would be to
support multiple transformers. But, it isn't it's required to have
this, since a single custom transformer can be written which just calls
each of the additional desired transformers.
Sorry I don't have more constructive/concrete suggestions. I'll keep
thinking about it. The more I work w/ the framework, the more I
understand what it's doing and intent. :)
I'll take a look into the RAW type again. I got stuck with file uploads
and mime-types when I first plunged into RIFE, and I've learned a lot
since then. Heck, I've learned a lot since 2 nights ago. :)
At any rate, I think adding MimeTypes would be a big advantage. There
are a lot of MimeTypes out there, and being able to publish and download
additional handlers would be awesome. Now that I think about it, maybe
the whole CMF system should really be constructed in terms of pluggable
MimeType handlers, then provide some default implementations for the
currently supported types.
Thanks again for an awesome framework! :)
Shalom,
Josh
Geert Bevin wrote:
Hi Joshua,
currently there is no extension mechanism for this, but I'm willing to
look into any proposals since this rigidness has always troubled me.
With the enum mechanism that we use in RIFE, you can add any other
MimeType but the constructor is currently too closed down, maybe it
should just be made public. This means that you would be able to add new
MimeTypes.
One thing that you have to realize though, is that MimeType entries
specify how they they are validated and formatted, they don't however
indicate where they need to be stored. This is a tricky thing to solve
since the content storage back-ends are abstracted away and currently
detect directly on the MimeType enum elements (they provide a collection
of MimeTypes that they're able to handle). When you add your custom
MimeTypes, those storage backe-end wouldn't be able to handle them
though. This is sadly currently hardcoded in the constructor of the
DatabaseContent class and ideally it should be opened up. Doing this,
you could add your own content store (that could extend an existing one)
and add the MimeTypes that this one supports.
I'm curious to see what you want to do with a custom IMAGE_JPEG
loader/formatter? What actually happens is that RIFE tried to load any
possible image, not just JPEGS. To do this is goes over the image loader
backends it knows about. These are setup in ImageContentLoader. Ideally,
this order should also become configurable. The JPEG type is only used
for the format of the final image storage (the loaded image will be
transformed into the target type). If you just want to store anything
as-is, use the RAW type. Note that you can always change and interact
with your content by using a ContentTransformer. We chose to use the
standard java.awt.Image type as the format into which to load the images
before writing them out again. If you want another type, you can use the
RAW type with your own ContentTransform to handle it the way you want.
Hope this helps.
Best regards,
Geert
On 08 Dec 2006, at 17:56, Joshua Hansen wrote:
Hi Geert (and others),
I've been working a little with the CMF and I was wondering: is it
possible to specify a custom MimeType class? I can't extend it
because the constructor is private, and I can't reset the static enum
defs (IMAGE_JPEG, IMAGE_PNG, etc) with custom versions for the same
reason.
I'd like to add new MimeTypes, and or replace existing types, such as
to use a custom IMAGE_JPEG loader/formatter. A specific example would
be to use a more efficient third party or native library for image
manipulation/handling (instead of java.awt.Image).
I'm using RIFE 1.4.
Shalom (complete peace),
Josh
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
