Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [New Proposal] An Imaging wrapper package
From: "Abey Mullassery" <abey@mullassery.com>
Reply-To: "Abey Mullassery" <abey@mullassery.com>
In-Reply-To: <20040507094643.E088.DEV.JEREMIAS@greenmail.ch>
References: <20040506211945.16BC.DEV.JEREMIAS@greenmail.ch>
	<20040507105627.1049646732.abey@mullassery.com>
	<20040507094643.E088.DEV.JEREMIAS@greenmail.ch>
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0
Message-Id: <20040507160752.456439281.abey@mullassery.com>
Date: Fri, 7 May 2004 16:07:52 +0530


Thanks a lot for the detailed mail and very useful suggestions.

> I agree with Martin that Apache Commons would be a better place. Another
> place could be the shared code base in the upcoming XML Graphics project
> but I think Apache Commons is still preferred. I'd rather not have such
> a package outside the ASF if possible. There are enough potential custome=
rs
> here that we can justify a shared ASF-homed API adapter for images.
> =


That was my understanding as well eventhough upcoming XML Graphics project =
was news to me. I personally would love to share this code with ASF than an=
ywhere else.
Since many of you say that its better fit to be an Apche commons project, I=
 will send this proposal to the Apache-commons list. Is the procedure same =
for Apache Commons as well?

But I think it is best to propose the package to Apache commons after we re=
define the scope based on the feedback that we have got here. I started wri=
ting this library for myself :-) and hence I designed it in such as way tha=
t was easy for me to use (for Image Taglib and Image ANT Tasks). However it=
 is just in a preliminary stage to be an apache commons package.

> As for the scope, I think you're already on the right track. If I were
> to define the scope without already looking at what you've done, I would
> do it like this:
> - Functionality defined by interfaces.

Yes. =

It has ImageLoader (wanted to name it ImageIO), ImageTransformer and an Ima=
ging interface extending the other two.

> - Central factory for getting (and registering) implementations for
> these interfaces. Possibly auto-discovery of available implementations.

Yes. =

ImagingFactory by default gets you a JAI based support if available, if not=
 Java2D (Imageio or plain AWT). It could also be specified explicitly.

> - Support for multiple image libraries simultaneously (not all libraries
> support the same set of codecs).

Somewhat. =

JAI an Java2D support is available. GIF encoding support comes from pjatool=
s if available but this has a lot of room for redesign.

> - The above makes it necessary to have code to detect the image format
> when loaded from an InputStream without a MIME type available. FOP
> already has code for that.

Not available. =

This would be a great feature to include.

> - Support for prioritizing the image libraries to be used.

Not available. =

The JAI support is used if available. If not it defaults to Java2D. =

In the same way for loading it tries to use ImageIO or defaults to AWT.

> - Main adapter interface should expose load and save functionality.
> - Image manipulation should be a different set of interfaces as most
> applications will only use the load/save part. The extent of the image
> manipulation functions available would have to be defined further.

Somewhat.
The IO functionality is exposed by the ImageLoader interface.
The transformations are exposed byt he ImageTransformer interface.
But both are commonly exposed by the Imaging interface. maybe this requires=
 some change of design.

> - a codec library would probably be out of scope but could be done later
> if there's enough interest.
> =


Not available.
Formats like Dicom, Flash etc., could be useful.
It has to be redesigned to add such capabilities.


> An important point for applications that write images is support for
> metadata. ImageIO does a not so bad job here. Raises the question how
> much should be invested here and if this is really all necessary now
> that JDK 1.4 is already available for almost all platforms.
> =


Not available.
Need to look into this.


> Could you elaborate what you mean by "SVG operations"?

All I meant was a simpe interface with methods that take SVG string/file/st=
ream as input, does some manipulation on it and returns SVG.


Let me know your thoughts,


Abey Mullassery
http://www.mullassery.com


> =

> On 07.05.2004 07:26:27 Abey Mullassery wrote:
> > =

> > Thanks for the pointers and the suggestions.
> > =

> > If there is a need for loading and saving images in various projects al=
ready wouldn't it be a good idea to create a common package. The primary go=
al of the package I proposed was to make it simple. All the feedback I get =
from the users of PMIW lauds this very point.
> > I had plans of including a simple wrapper for SVG operations as well bu=
t I thought it would force the package to do too many things and lose focus=
. =

> > =

> > Please add your comments and suggestions. =

> > If you think that we need to redefine the scope before the can think ab=
out including it in the commons, we could do that as well.
> > Can this be included into a similar project that is now in the proposal=
 stage (like XML-Graphics)?
> > If you think that Jakarta-commons is not the right place for this packa=
ge, please suggest another place. Would Apache-commons be a better place?. =
How about Java.net? =

> > =

> > My aim was to make the package (that supports Image Taglibs and Image T=
asks and being used directly) a public project so that many more can contri=
bute and will have much more functionality and feedback.
> > =

> > Eagarly waiting for your thoughts.
> =

> =

> =

> Jeremias Maerki
> =

> =

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> =

> =


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org