Hi everyone, I will try to explain our motivation to maintain two models (SF an CF) in trunk.
1) Client or users view Current Applications: this applications can be improved or not, this is a fact that we can not handle because it depends on external factors. If that application can not be improved, I think, the geotools project must give minimal support like bug fixes. That is important to have a confidence relationship with stakeholders. Future Applications: if some stakeholders are thinking in new projects I suppose that they will select the more powerful toolkit. If geotools implements CF will have a competitive vantage. I do not think that newcomers will select the old model if they have something better. 2) Geotools Activities Bug fixing: as I have written before, it will be needed a minimal maintenance of SF, it can be easier if we abstract out functionalities used in both models, then if we have a bug in an abstract component the fix will solve the problem in the toolkit for both SF and CF. You know maintenance is the activity that spends more resources in the software life cycle. New components: constructing new components like those required for CF will be more safe and easy if we first refactor SF in abstract concept that can be used to develop the new model. This strategy will produce a high quality product that is derived from safe functionalities. The task of abstract behavior can be a bit hard now but that component have a best probability to survive the future changes. Regards On Thursday 23 November 2006 13:41, Gabriel Roldán wrote: > ---------- Forwarded Message ---------- > > Subject: Re: [Geotools-devel] FM on trunk mad plan - feedback required > Date: Wednesday 22 November 2006 21:54 > From: Rob Atkinson <[EMAIL PROTECTED]> > To: Gabriel Roldán <[EMAIL PROTECTED]> > Cc: GeoTools Devel List <[email protected]> > > From experience with this, whilst I agree with Justin about more > efficient use of resources to make the move, I think the proposal has > the balance right: > > we already have a bunch of data stores with low maintenance levels - > updating all this simultaneously will be a nightmare. > > So: > > a) provide the new functionality > b) move geoserver and UDIG to use it > c) create new versions of old data stores based on new model > d) turn existing data stores into old model wrappers of the new ones > e) make sure all CITE tests, unit tests are against the new model > f) deprecate the old model > > Given that C) will take an uknown amount of time, getting to F) will be > too long to contemplate in a single project > > In terms of motivation to use it - this will be driven by data standards > - which is a whole theme that the geotools community has been less aware > of, but will drive institutional uptake. We just doint see the demand > because we dont offer the functionality. I'll make a predicton now that > publicaly visible deployed WFS services will _all_ need to use the > SchemaMappingDS (renamedit - but maybe SchemaAwareDS would be better?) > > robA > > Gabriel Roldán wrote: > > 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. > > > > Gabriel. > > ------------- > > > > you there? > > I have updated the proposal page > > http://docs.codehaus.org/display/GEOTOOLS/FM+on+trunk+proposal > > Justin Deoliveira: yup > > still a draft though > > Justin Deoliveira: alright, let me give it a quick read > > hi, how is it going? > > Justin Deoliveira: not bad, just working on passing wfs 1.1 cite tests > > wow, sounds challenging ;) > > Justin Deoliveira: not too bad > > Justin Deoliveira: ok, i understand your approach better now > > Justin Deoliveira: and i agree that it would work well for you, and not > > really mess with the rest of the code base > > Justin Deoliveira: but... > > Justin Deoliveira: i think we need to mess with the rest of the codebase > > Justin Deoliveira: i for one would like to see one feature model > > Justin Deoliveira: especially since it already cators to the simple case, > > with SimpleFeature, SimpleFeatureType, etc.. > > hmmm... seems I did not make clear that it is meant to allow for a smooth > > upgrade path to a single feature model.. > > Justin Deoliveira: i can see that is todes > > Justin Deoliveira: however > > todes? > > does? > > Justin Deoliveira: sorry > > Justin Deoliveira: it does > > Justin Deoliveira: but > > Justin Deoliveira: it will acheive its goal without making it necessary > > to move over > > Justin Deoliveira: which brings no motivation to move over > > so you do think a full move is more workable? like people will be ok in > > doing a full move instead of having more time to test, verify, adapt > > Justin Deoliveira: no i dont :) > > Justin Deoliveira: I think your approach is much easier > > Justin Deoliveira: however... > > but think people's gonne be lazy on adopting the new model? > > Justin Deoliveira: i think doing a full move makes it explicit, and will > > hammer out all the problems up front > > Justin Deoliveira: thats the point > > Justin Deoliveira: i dont think this can be a success without major buy > > in from everybody > > which can well never happen, I guess > > I think there is more stuff to take in count, we're a library with a lot > > of users, users have applications running that they don't want to be > > broken from night to day > > Justin Deoliveira: so... > > maintenability is key > > Justin Deoliveira: here is my take on it > > Justin Deoliveira: i think your approach is good and will work, but i > > dont think anyone will ever end up using it because its "off to the side" > > Justin Deoliveira: however it is less painful > > I think you're wrong just in that point, however. The point is there > > already are people that's willing to use it! > > actually they want to invest money to use it > > Justin Deoliveira: how is that differnt then complex features? > > hate that the word "money" comes into play, lets keep the focus on > > "users" and heck, each time more users are jumping on asking for > > community schemas support > > and more will come now that INSPIRE was just approved > > it is different from complex-features precisely in that now we don't need > > a library wide move or nothing, we're providing an innovation path and a > > maintenance path > > remember we flicked out on the imposition of having to port all > > datastores, for example > > Justin Deoliveira: but not a motivation path :) > > Justin Deoliveira: fair enough > > Justin Deoliveira: i guess my issue is not at with your approach, > > actually it is the exact approach i would like to use to do the work > > Justin Deoliveira: i guess my concern is just a politcal one in that i > > would like to get agreement in that we *have* to move to the new model, > > having two is not acceptable > > Justin Deoliveira: but that is just my opinion, others may wish to have > > two models around > > hmmm... we should have to find that motivation based on success, not only > > in theory. And having two is completely acceptable from a object oriented > > approach standpoint > > hey, I very appreciate your opinion and feedback > > and knew beforehand I was going to have to defend my proposal, so good > > excercise ;) > > you mind if I post this chat? > > Justin Deoliveira: fair enough, but i dont think that using oo to > > validate it really means much, i mean we could design it using aspects > > and using aop to validate it, that doesn';t mean it is a good idea > > Justin Deoliveira: but i see your point > > Justin Deoliveira: not at all > > Justin Deoliveira: i think you should post the chat, and fire up an email > > converstation on the list > > cool, thanks > > Justin Deoliveira: where i will raise my concern ( and opinion ) that i > > dont think its enough to just ok the work, i think its necessary to > > create a mandate to actually unify the models > > hmmm... anyhow, will it really hurt having it as an unsupported module? > > Justin Deoliveira: no, but it will reduce what we can gain > > I think it'll serve as a proof of concept and to gain visibility on the > > work done and what it allows for. Think the majority of developers don't > > really know what all this community schema work is about > > Justin Deoliveira: i agree > > Justin Deoliveira: i think the approach is great and the right way to do > > it Justin Deoliveira: so in terms of your proposal i dont have any > > objections so, it's gonna be easier to say go check the xxx module in > > trunk then saying "check out complex-stuff branch, build, download > > geoserver-cpx branch, build, test, what do you think?" > > nobody's gonna take the time to do that > > Justin Deoliveira: sure, but what about conflicts between the old feature > > model and the new one > > fair enough, I'll send this to the ml to keep getting feedback. Tons of > > thanks man > > Justin Deoliveira: that could be a potential hurdle as well > > Justin Deoliveira: but anywho, no problem > > what kind of conflicts? > > Justin Deoliveira: like class names > > we have packages > > Justin Deoliveira: so org.geotools.feature and org.geotools.feature2? > > both are actually private from a design point of view, you should use > > them from the factories > > so, org.geotools.feature.geoapi, for example > > is a private package > > unfortunatelly we cannot hide them like in rcp > > Justin Deoliveira: fair enough > > Justin Deoliveira: but none of the geotools client code treats them as > > private Justin Deoliveira: but that is a differnt issue > > Justin Deoliveira: anyways, with some documentation others will have to > > chance to voice their opinions, like jody and andrea > > the current stuff not, but that remaing untouched > > the new stuff HAVE to be used trhough the interfaces > > Justin Deoliveira: which is the part i dont like, the old stuff being > > untouched > > that's quite the point, I don't plan to the a wide move, just add > > functionality non intrusively > > Justin Deoliveira: I know, your approach is the same one i am using for > > the new xml stuff > > the rest more a community wide job > > Justin Deoliveira: i am not sure you understand my concern > > oh, probably > > Justin Deoliveira: i my concern is that the geotools project needs to > > decide to move to a new feature model, beacuse the old one really sucks ( > > as you know ) > > Justin Deoliveira: doing things non-intrusivley is nice for those people > > who are happy with the old model, but not for us who want a new model > > Justin Deoliveira: and not because it doesn't give us a new model > > Justin Deoliveira: because it does > > Justin Deoliveira: but it makes us have to deal with people who still wan > > tto use the old model > > Justin Deoliveira: which is where my concerns come i n > > Justin Deoliveira: anyways, i can bring up again in email > > ok, thanks man > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------- -- Mauricio Pazos Director Axios Engineering www.axios.es e-mail: [EMAIL PROTECTED] tel-:+34 94 441 63 84 fax: +34-94 441 64 90 ------------------------------------------------------------------------- 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
