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.

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.

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.

Cheers,
Walter
- Show quoted text -

On Tue, Aug 9, 2011 at 10:54 PM, Andrea Aime
<[email protected]>wrote:

> On Tue, Aug 9, 2011 at 3:06 AM, Walter Deane <[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
>
> -------------------------------------------------------
>

<<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

Reply via email to