incubator-kato-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Pilkington <pilkington.a...@googlemail.com>
Subject Re: How to start using the Image API ?
Date Wed, 13 May 2009 18:33:04 GMT
How about the ImageServiceProvider ?

2009/5/13 Steve Poole <spoole167@googlemail.com>:
> 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
>>
>



-- 
Regards

Adam Pilkington

Mime
View raw message