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?
On Tue, Aug 24, 2010 at 10:29 AM, Andrea Aime <[email protected]> wrote:
> Justin Deoliveira ha scritto:
>
> Hi all,
>>
>> I had some thoughts about how to extend our extension lookup mechanism
>> slightly and wanted to start some conversation on the subject.
>>
>> My use case is that I want to contribute implementations to the various
>> geoserver extension points, output formats, transaction hooks, etc... from
>> python (or any scripting environment for that matter). And I don't really
>> want to register beans in the spring context and restart the server when i
>> add a new one.
>>
>> So, the idea. The idea is to add a new interface called ExtensionProvider
>> that would look something like this:
>>
>> interface ExtensionProvider<T> {
>> List<T> ExtensionProvider(Class<T> extensionPoint);
>>
>> }
>>
>> Implementations of which would be registered in the spring context as per
>> usual. Then modify the GeoServerExtensions class to use any instances of
>> this interface when being asked to do an extension point lookup.
>>
>> Thoughts? Comments?
>>
>
> Sounds like a good idea, there is a catch though.
> The Spring lookups are heavy so we cache the results, what are we
> going to do with this new extension source?
> Is it supposed to be fast enough that we can query it every time?
>
> 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
