Re: [Geotools-devel] Questions stemming from documenting the design

[James M. <j.m...@ge...>]

At 13:09 01/10/2002, Cameron Shorter wrote:
>On Tuesday 01 October 2002 18:28, James Macgill wrote:
> > In addition, I would like consider making the
> > core API module external to the GeoTools project at some point in the
> > future.  This makes it possible for other projects to produce code that is
> > compatible with GT2 without having to use any of its code.  Ideally the
> > core module would become part of a shared project that other open source
> > projects can use and develop.
>
>In this case, I would have thought it would be better to have multiple core
>modules:
>core-filter, core-datasource, ...
>Then external packages only need to include the interface they are interested
>in, not the entire geotools suite.

Interfaces are very light so I don't think anyone would mind picking up the 
whole set, and besides they are in separate packages so it would still be 
easy for someone to pick out the filter related interfaces if they wanted 
to.  I do not want the modules to proliferate to a one per package 
situation, remember also that there is extensive dependances between the 
interfaces, for example core-filter would require core-feature.

On the other hand, I agree that defaultcore could benefit from being split 
as there may be people interested in only some parts of it.

At the moment, if you look at defaultcore, it only implements part of core 
anyway as other parts of it are left to other modules....

i.e. at the moment defaultcore implements the feature, style, filter and 
map aspects of core but not rendering or datasource.  As a result there may 
be scope for...

default-feature, default-style, default-map and default-filer as separate 
modules, this would help expose what was happening within defaultcore.  It 
may also be a good idea to move away from default as a name and perhaps 
adopt something else... e.g. one of simple-styling, j2se-styling, 
basic-styling.......

This would resolve one area of current confusion as at the moment as people 
may think that the current filter module is actually responsible for 
filtering, it is not.  The filter module is only responsible for converting 
an XML encode Filter into filter objects.

Cheers

James


-- 
James Macgill
Center for Computational Geography http://www.ccg.leeds.ac.uk
Spell Checker (c) Creative Spelling inc (aka my dyslexic brain)
http://www.geotools.org a client side java mapping toolkit.