The other thing is to list a task for each module; as each module maintainer 
should be able to update their own section. You know team work...

-- 
Jody Garnett


On Friday, 3 June 2011 at 5:26 AM, Andrea Aime wrote:

> On Thu, Jun 2, 2011 at 9:20 PM, Andrea Aime
> <[email protected] (mailto:[email protected])> wrote:
> > On Thu, Jun 2, 2011 at 4:25 AM, Jody Garnett <[email protected] 
> > (mailto:[email protected])> wrote:
> > > 3. Assuming (1) should we simply add to the FilterVisitor interface 
> > > breaking
> > > direct implementations, or come up with subinterface or the like to 
> > > capture
> > > the temporal methods so that we do not break client code. If we do think 
> > > the
> > > latter is a good idea then perhaps it makes sense to do the same for 
> > > filter
> > > factory.
> > 
> > I don't know much about the temporal module, hopefully Simone and Daniele
> > or Alessio will chime in (warning, this is a long weekend in Italy).
> > 
> > As for the interfaces I agree with Jody, we still have scars from the
> > last filter
> > update, made half way and never completed (and still it is not complete,
> > FilterCapabilities anyone?).
> > Better move the interfaces you need among the api and break solid
> > whatever needs to be broken, so that we don't have to spend the next
> > year chasing temporal filters disappearing halfway in a style duplicator,
> > a attribute visitor or a xml dumper (just to make an example).
> 
> Uh, btw, I understand that dealing with temporal filters everywhere is
> a massive undertaking. A reasonable approach could be to:
> - update the primary filter visitors, the ones that are not store specific,
>  like duplicators, attribute extractors.
> - throw UnsupportedOperationException("Temporal filters not supported")
>  everywhere else, a fail fast message that makes it clear the time support
>  is not there for that specific store, and that can be easily searched for
>  by store maintainers willing to add temporal filter support.
>  It would still be long and tedious, but you could get away by
>  implementing once the block of visit methods throwing the exceptions
>  and pasting it in all visitors that you don't know/don't have time
>  to actually fix
> 
> Just my 2 cents
> 
> Cheers
> Andrea
> 
> > Cheers
> > Andrea
> > 
> > --
> > -------------------------------------------------------
> > Ing. Andrea Aime
> > GeoSolutions S.A.S.
> > Tech lead
> > 
> > Via Poggio alle Viti 1187
> > 55054 Massarosa (LU)
> > Italy
> > 
> > phone: +39 0584 962313
> > fax: +39 0584 962313
> > 
> > http://www.geo-solutions.it
> > http://geo-solutions.blogspot.com/
> > http://www.youtube.com/user/GeoSolutionsIT
> > http://www.linkedin.com/in/andreaaime
> > http://twitter.com/geowolf
> > 
> > -------------------------------------------------------
> 
> 
> 
> -- 
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
> 
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> 
> phone: +39 0584 962313
> fax: +39 0584 962313
> 
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
> 
> -------------------------------------------------------

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to