Sounds reasonable to me. Thanks for the feedback Andrea.
On Tue, Aug 24, 2010 at 1:14 PM, Andrea Aime <[email protected]> wrote:
> Justin Deoliveira ha scritto:
>
> Well my thought is that the lookup for the ExtensionProviders themselves
>> will be cached so as long as the ExtensionProvider implementations
>> themselves are fast then it should be fast enough to query them each time.
>> However is one is slow then the entire lookup will be slow. And in the case
>> i am working on it will involve going to disk to check for new script files
>> and parsing scripts... However the case of contributing extensions via
>> scripts a cache would be problematic as the available extensions is likely
>> to change.
>>
>> Perhaps could add another cache for specific to ExtensionProviders
>> themselves. And perhaps add a flag to the ExtensionProvider interface
>> itself:
>>
>> interface ExtensionProvider {
>> boolean isCachable();
>> }
>>
>> to allow the implementation the choice of whether it should be cached or
>> not. Or perhaps be a little smarter and allow the extension to report when
>> it needs to be reprocess:
>>
>> interface ExtensionProvider {
>> boolean isModified();
>> }
>>
>> Thoughts?
>>
>
> Well, in the end a FS based one is not cacheable. Having a way to
> cache the result until modified could be intersting to factor out
> code, but that can be also provided through a wrapper (or base) class
> which factors out this caching aspect.
>
> In the end I don't think it'll buy us much... I mean, we should
> just tell the implementors of those providers that:
> - lookups for a class other than the one they produce should
> be damn fast (e.g., check that in the first row of your method,
> or have the provider declare what kind of extension it generates)
> - lookups for the specific extension point should be as fast as
> possible, knowing that a slow one will drag down the entire
> system with itself.
> Eclipse has this issue and I think it ends up banning extensions
> that take too much time to process a certain extension point.
> Could be a way, but it can also be added later: for the moment let's
> just try document it and be careful?
>
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
