Walter perhaps an RnD wiki page would be a more suitable venue for discussion / collaboration between modules.
I have a similar RnD page here for the process work: - http://docs.codehaus.org/display/GEOTOOLS/Process+RnD As you can see it is mostly my notes as I go through the steps of taking the Process interfaces up to supported status. Perhaps a similar approach will work here? Only trouble is introducing a dependency from VersioningFeatureStore over to ArcSDE if gabriel has time to try an implementaiton. I think if the interfaces / direction is agreed the first cut of the interfaces can be prototyped in postgis-versioned as part of backing it on to a jdbc-ng foundation. -- Jody Garnett On Tuesday, 9 August 2011 at 11:09 PM, Jody Garnett wrote: > Andrea do you have another suggested way to work on this then? So far a > proposal is the only way we have to communicate. We are not going to start > implementing with out a direction. > > -- > Jody Garnett > > > On Tuesday, 9 August 2011 at 10:54 PM, Andrea Aime wrote: > > > On Tue, Aug 9, 2011 at 3:06 AM, Walter Deane <[email protected] > > (mailto:[email protected])> wrote: > > > > > > I have put up a new UML that reflects Andrea's naming changes and Jody's > > > request not to have a locking dependency. > > > > > > http://imgur.com/83RdW.png > > > > Still not good imho. > > VersioningFeature is similar to SimpleFeature, DecoratingFeature, > > ResultSetFeature, > > TestFeature and so on (all available in the code base).. except it's > > not a feature. > > It should be either VersioningFeatureStore or VersioningFeaturLocking, since > > it allows to modify the data contents. > > As a rule of thumb, in GeoTools you do "if(fs instanceof FeatureStore)" to > > know > > if a object is also able to mutate the contents of the store. A > > rollback does that, > > so it should follow the same conventions imho. > > > > The remaining main problem I see in the proposal is that you're trying to > > push > > out new interfaces that have no implementation in supported land. > > This is unprecedented and dangerous. > > > > Look around and you'll see that interfaces in current use have landed > > in core only > > along implementations of them in the same commit. > > The few ones that did not are the classic dead bodies that we have around > > in the code, stuff that people added and then failed to complement with > > implementations. > > > > Not saying that it's going to happen with this one as well, but why not > > follow > > a path that makes sure it cannot happen at all? > > With naming fixes I'll still vote -0 on the proposal (with the current > > naming > > my vote is still -1). > > > > 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 > > > > ------------------------------------------------------- > > > > ------------------------------------------------------------------------------ > > 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] > > (mailto:[email protected]) > > https://lists.sourceforge.net/lists/listinfo/geotools-devel >
------------------------------------------------------------------------------ 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
