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.
------------------------------------------------------------------------------
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
