incubator-kato-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: How to start using the Image API ?
Date Wed, 13 May 2009 13:53:42 GMT
On Wed, May 13, 2009 at 1:50 PM, Adam Pilkington <
pilkington.adam@googlemail.com> wrote:

> I've been looking a bit further into the issue of bootstrapping the
> ImageFactory and one possible solution is to use the  functionality
> which is provided by the javax.imageio.spi.ServiceRegistry class. This
> seems to provide a simple mechanism by which a service provider (in
> this case an implementation of ImageFactory), can register itself and
> then be subsequently invoked. However the one thing that does concern
> me is that this mechanism only supports a single service provider
> (full details are on the JavaDoc page for ServiceRegistry) and that
> could be a problem in a situation where you may want to offer the user
> a choice of ImageFactory implementations e.g. an Eclipse plugin
> whereby you can highlight a core file and choose which implementation
> to analyse it with.
>
> 2009/5/8 Adam Pilkington <pilkington.adam@googlemail.com>:
> > I've recently been writing some Eclipse plugins to use Kato, in
> particular a
> > runtime explorer, and I came across the issue of how you actually start
> > using the API when the first step is creating an instance of a concrete
> > implementation of ImageFactory. How do we ensure that we don't end up
> > building against a particular implementation and also that we can easily
> add
> > others at a later point in time. I know that Eclipse provides an
> extension
> > mechanism that handles part of this problem but at some point you have to
> > connect up to the actual implementation of the API (this of course
> assumes
> > that Eclipse is being used as the delivery platform rather than something
> > else).
> >
> > One possible solution that comes to mind is that we extend the
> ImageFactory
> > API to enable provider specific information to be retrieved e.g.
> > getProviderDescription, getProviderMajorVersion and
> getProviderMinorVersion.
> > If we consider an Eclipse based scenario then a particular provider can
> use
> > the extension point infrastructure to identify itself to a tool, and then
> > using the provider information, the toll could give the user the choice
> of
> > which one to use.
> >
> > --
> > Regards
> >
> > Adam Pilkington
> >
>
>
>
I wrote a testcase using this API  and it seems to do exactly what we want
-  this has been around since 1.4.2!

I think that this makes life very easy for us -  the only restriction seems
to be that you'll only be able to have one provider per jar.  So we'll
probably have to have some sort of delegate provider that registers the
other providers it knows about directly.  (read ImageFactory for provider
here)


$64000 question -  what do we call the mega factory that is going to manage
all the imagefactories?




>
> --
> Regards
>
> Adam Pilkington
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message