Hi Gabriel - I am going to do an experiment (in the jpox module) to see how well things can work out ...
Basically: - make DataAccess a proper superclass of DataStore - hack away from there ... It is amazing what becomes possible the moment we had our Filter / Data / Metadata seperation sorted out like a proper architecture :-) The experiment may fail - but we will know either way fairly shortly; I will upload a picture to the JPOX page here: - http://docs.codehaus.org/display/GEOTOOLS/JPOX+Extension And of course your feedback would be much helpful. Jody > Hi Gabriel: > > I am pretty set on getting rid of the old feature model as quickly as > possible - more from a standpoint of staying focused > then anything else. I really want 2.4 to be the last release with this > feature model, and to have all the work needed to > adopt the new one out of the way. > > To wit I have created a "data" module (again - this was done on the FM > branch); where compile time will *not* depend > on "main"; but test time will. This will ensure we use the common > factory finder, and are careful about acquiring all our > feature factories through injection. > > I would like to see your "fm" module started; by way of getting a jump > start on the coding needed for GeoTools 2.5. > > I must stress that this is simply a negotiation of scope and resources; > if keeping the old feature model in zombie state > will help on resources I am for it; right now the increase in scope does > not look worth it (and the risk of code not > being caught out would be horrible). > > So if that wide adoption of the current feature model is indeed a factor > - lets scare up some volunteers for this work. If > that volunteer is in fact you (are you scared up?) can I ask that we > isolate the old feature model to a separate module so > we still get the maven sanity check to "catch out" code in the manner I > desire? > > Please note that both SimpleFeature and org.geotools.feature.Feature > make use of an array of Objects to store their values > so converting is easy even if a class cannot implement both at once. > Indeed you could inject a factory of the form: > interface new DataWrangleFractory { > Object createData( Object[] values ) > } > Into something like the FeatureReader interface and produce content from > either feature model. I had considered limiting > our Pojo support to Pojos that implement Feature; if the above approach > is of interest (and would enable you to keep the > old feature model around for backwords compatibility) then we can > consider it in more detail. > > Gabriel my priority this week is Expresion (and your new BNF parser) so > I may not be timely in response to email. > If you have a timeline/deadline to meet let's schedule a breakout IRC > meeting (or wait until Monday). > > Great to have you back on trunk - you have been missed. > Jody > >> Hi list, >> I have updated the proposal page for bringing community schema (aka, >> complex-features) support into trunk: >> http://docs.codehaus.org/display/GEOTOOLS/FM+on+trunk+proposal >> It is draft and completely open to discussion. >> >> bellow is some early feedback from a chat with Justin, would appreciate >> comments from anyone. >> >> > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
