> This is quite near to what is my personal thinking.
> See also this post of mine (sorry for the different Subject):
> "Ideas on versioning" (on the geotools-devel list)
>
Since it has come up in a couple of peoples ideas. With respect to
making a VesioningDataStore... Lets not.Please lets just treat versioning as a first class concern and change
the DataStore API. The OGC has version and timestamp modeled
as being
part of what defines a Feature (just the same as feature ID).
Could you please point me to the relevant document from OGC???
I looked at http://portal.opengeospatial.org/files/?artifact_id=890
but it doesn't seem to contain anything that will let us implement a
Feature.getVersion() method, but I may have missed it, or it's in another
document.
So lets make sure the geotools system is rich enough to capture this
idea of a Feature, and lets change the DataStore API to take
advantage
of that fact.Jody
For what it counts, I'm against changing APIs for whatever reason,
and even if you do that it would not be sufficient, because versioning
must also implemented.
Since it may not be that easy to implement, it could turn out that
implementing it and making available through the DataStore API
is too difficult. So I feel it's better to discuss first, at least briefly,
of implementation first.
I agree that versioning should be treated as a first class concern
and that a VersioningDataStore may not be sufficient alone
and that the right thing to do may be changing the DataStore API.
However you must anyway actually implement versioning somehow,
and a VersioningDataStore could be something that can transparently "add"
versioning to any already available DataStore, without the need to modify
them all.
Bye
Paolo Rizzi