Hi,
I've just got a basic FTP server module working.
However, it's working with some built-in defaults
that the administrator needs to configure, most
importantly the FTP port itself (by default it will
be 8021, do you think it's a good default?)
So I need to roll out a configuration object and
manage storage for it, and I would really like
to avoid rolling yet another property file...
would feel quite a bit better to be able to
use a GeoServer pluggable extension point instead.
Now FTP is a service, so ServiceInfo would seem
like a match... there are however a couple of issues:
- there is a number of extra things there that are
OGC specific (I guess I could just ignore them)
- a FTP capabilities link will pop up in them main
page if I go that way.
Soo... what shall we do? I guess an easy way would
be to add a flag in the ServiceInfo object,
isOGCService() to mark the ogc services (on by default)
or else to roll out a subinterface, OGCServiceInfo,
or a marker interface, OGCService....
Opinions?
In general, how would you address pluggable configuration
storage?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Trying to use ServiceInfo for something like this does not seem quite right since as you mention it is really geared toward OGC services. Even if we did add a flag to mark a service as an OGC service it would still seem a bit heavyweight to use it.
As you mention the alternative has been for people to use property files. Which seems like a good idea if the file is to be directly edited by the user. Is this the case here?
An alternative would be to roll a lighter weight alternative to the ServiceInfo marshaling/marshaling that does not require an object to implement the ServiceInfo interface. Actually the ServiceLoader class is pretty generic, perhaps it could be used? Creating a subclass that just did a straight xstream marshaling/unmarshaling? Or perhaps not xstream and still make it property file based. Providing the file water facility to enable changes to be loaded on the fly? Just thinking out loud here.
2c.
-Justin
On 10-06-01 9:44 AM, Andrea Aime wrote:
Hi,
I've just got a basic FTP server module working.
However, it's working with some built-in defaults
that the administrator needs to configure, most
importantly the FTP port itself (by default it will
be 8021, do you think it's a good default?)
So I need to roll out a configuration object and
manage storage for it, and I would really like
to avoid rolling yet another property file...
would feel quite a bit better to be able to
use a GeoServer pluggable extension point instead.
Now FTP is a service, so ServiceInfo would seem
like a match... there are however a couple of issues:
- there is a number of extra things there that are
OGC specific (I guess I could just ignore them)
- a FTP capabilities link will pop up in them main
page if I go that way.
Soo... what shall we do? I guess an easy way would
be to add a flag in the ServiceInfo object,
isOGCService() to mark the ogc services (on by default)
or else to roll out a subinterface, OGCServiceInfo,
or a marker interface, OGCService....
Opinions?
In general, how would you address pluggable configuration
storage?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Trying to use ServiceInfo for something like this does not seem quite right since as you mention it is really geared toward OGC services. Even if we did add a flag to mark a service as an OGC service it would still seem a bit heavyweight to use it.
As you mention the alternative has been for people to use property files. Which seems like a good idea if the file is to be directly edited by the user. Is this the case here?
I actually would like to make a GUI for this.
Though, of course, the GUI could work out of a property file if we want
to.
It's just that keep on using property files strikes me as wrong... I went that way in times in which touching the config subsystem was
suicidal (1.6.x) but today I'd really wish to have something in
the config framework to cater for this need.
An alternative would be to roll a lighter weight alternative to the ServiceInfo marshaling/marshaling that does not require an object to implement the ServiceInfo interface. Actually the ServiceLoader class is pretty generic, perhaps it could be used? Creating a subclass that just did a straight xstream marshaling/unmarshaling? Or perhaps not xstream and still make it property file based. Providing the file water facility to enable changes to be loaded on the fly? Just thinking out loud here.
water -> watcher (right?)
I guess we could. As far as I can see GeoServerLoader tries to match
these ServiceLoaders with a ServiceInfo and ends up invoking:
loader.save( service, geoserver );
So even if service is not a ServiceInfo the logic in the loader is
based on the ability to enumerate those services somehow.
Or else we have a separate, similar interface that does not require
that argument and just has save(geoserver)/load(geoserver) and
knows what to save without being told...
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.