On Wed, Aug 10, 2011 at 8:59 AM, Walter Deane <[email protected]>wrote:
> Oops again. Forgot to reply all. Been a good day.[?] > > Oops, It was suppose to be VersioningFeatureStore I got a bit > overzealous in my deleting in the UML diagram. I am not familiar with the > commit process other than what I have read in the developer guide. I was > really trying to get guidance on making sure that any work that I attempt > will be eventually useful after review. Perhaps I should try and contact > Justin on the list as he is the maintainer of the JDBC module about how I > can develop an unsupported postgis versioning module that can eventually be > reviewed and possibly added. > Imho at this point you should focus on getting the store back in supported land. This way the interfaces will follow inside the store (...) As for pushing them into core, unlikely until we have a second and/or a third implementation to validate them. As long as there is a single implementation you have to depend on it anyways to do versioning, so you don't really need to have them into core. The experience with GeoServer WFS-V and GSS show that you don't really need them in supported land either. > > I mentioned a bit earlier that my eventual goal is a versioned datastore > but I was having problems determining a path on how to do that as the new > JDBCDatastore is final and a lot of the support classes expect it. (there > would be a lot of duplicate support classes if I created a versioned > JDBCDatastore class). I wasn't trying to circumvent the need for an > implementation; I was trying to separate the 2 into separate issues (I think > I just haven't been that clear about that). We have been looking at some of > the other versioning work going on (e.g. GeoGIT) and potential upcoming > development (e.g. wfs 2.0 versioning) and we just wanted to make sure that > we could all consolidate interfaces in the future. If the module maintainers > were interested that is to say. > There is no consolidation to be done here. As long as all you have is a single implementation you don't know if the interfaces are any good, so they are no core material. > > Would it be better to approach it this way? Ask Justin for guidance on an > unsupported module and any advice about how he sees versioning being > implemented. Or is there a different procedure that should be followed? It > would just be nice to ensure that whatever work we do can be used by others > at the end of the project instead of just in our own app. > The first step in a civil society is to present yourself and your company, and then introduce work you're trying to do in some detail, so that people know what direction you're going and can provide suggestions. Example questions that such an introduction should answer: What problem are you trying to solve? What are the moving parts in the problem, what software is involved? What versions of GeoTools What other software does it affect? uDig, GeoServer? Are you going to try and take over the WFS-V in GeoServer, which is in supported status? Are you going to modify the code in ways that make that code break, thus breaking the GeoServer build? What about GSS? Are you going to rewrite the store from scratch, add/remove functionality? All you provided so far was more or less "I want to push these interfaces into core" without following the naming conventions of the project and without giving much of a context. New contributors normally start with patches or a new community module, not with a GSIP out of the blue :-) 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 -------------------------------------------------------
<<361.gif>>
------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
