> If we'll have any new functionality to add, we'll do that inside
> GeoServer, even if that new functionality would be better suited
> for inclusion in GeoTools.> There're some functionalities now present in GeoServer that we need
> to factor out. The main one is the code inside
> org.vfny.geoserver.wfs.responses.TransactionResponseI wrote that method and would love to know what your plans are.
> that we intend to separate from the WFS and HTTP related code.
> The result of this factoring-out would ideally go into GeoTools,
> but we'll leave it inside GeoServer instead.In my understanding that has largely been done, the GeoTools
DataStore interface
was constructed with that method in mind.
The DataStore interface works on a single source of information at a time
(a DB, a shape file, etc.), TransactionResponse instead works upon
a group of source of information. It's capable of modifying a whole
bunch of DataStores at a time, inside a single transaction.
Unfortunately its code is tied to WFS and HTTP, so it's unusable outside
GeoServer. But there are cases when you don't want to pass through XML
and HTTP to perform an action you can do directly (if you have a service
that operates upon a group of DataStores that lives inside the same Java
VM).
The same is also true for reading actions like FeatureResponse.
Basically we'd like to stop working against single DataStores, and start
working against a Repository (we call like DataEngine), so that you can
concentrate upon FeatureTypes/FeatureStores, regardless of where they're
stored.
This is also needed to implement some of the functionalities listed below.
> During this process we'll try to keep our branch updated from
> trunk as much as possible.
> A non comprehensive list of things that will go inside our
branch are:
> .) Security by FeatureType
> .) Security by AttributeType
> .) Security by Polygon
> .) Notification by Polygon
> .) Locking by Polygon
> .) Versioning
> .) DataStore pluggability
>
I would really like to know your intended approach, for the
following reasons. I
suspect running some metadata assoicated with the type
system, and wrapping
DataStores as required. There is already a
GeoServerFeatureSource that wraps
most access.
Yes, there'll be both metadata and wrapping.
GeoServerFeatureSource may be useful but, as I told, we'd like it all
to work even outside GeoServer.
Separatly I am revising the Feature Model with Gabriel and
would like to know
your thoughts on versioning. Will the simple String
getVersion() opaque String
(that geotools used to have) be sufficient, are you trying
for long transaction
support with branching and merging? Do you have any UML diagrams?
A String Feature.getVersion() method may prove useful, even if it alone
won't be sufficient. Versioning will have a mechanism to add a sort
of hidden table to any given FeatureSource that'll record all it's changes.
It'll have the same structure of the base FeatureSource but
with a primary key containing the version number too.
There'll a be a mechanism, probably hooked inside the factored-out
TransactionResponse, that will insert a record into the hidden table
for each modification of the base one.
Then we'd like to have a CVS-like system, that let you "checkout"
FeatureSources, work on them locally, and then "checkin" them back,
but we probably won't be able to implement it at first.
A simpler solution, that we probably are going for, is to not have
a branch-merge system, because that will require long transaction support
with concurrent modification resolution, but to implement a polygonal
locking system. So you can define a polygonal region and lock it until
you're finished working. Others will be prevented to work upon the same
region, but most of all they will graphically see the region itself,
so they'll never even try to and they'll be able to know who is locking it.
This is different from the WFS locking system in that you're not locking
the Features contained inside the region, but the region itself, even if
it's completely empty of Features.
> Regarding all the pieces of code that should go inside
GeoTools, it will
> be someone else, more involved with GeoTools, that will
decide if and how
> to actually move them.It is unfortant that GeoTools has let you down in this
manner, is there
something that can be fixed?> There will also be some code that will stay with our package names
> and that we'll put in the GeoServer SVN only as JARs (both
binary and
> source).
> This code would also be ported to GeoTools, we'd be happy
about that,
> but it will require someone else, more involved with
GeoTools, to decide
> if and how to actually move it.
Here I was thinking about the fact that part of our code may come out
to be of interest to others but maybe not, so we could leave it anywhere
until the PMC or whoever else has reviewed it and decided if and how
to integrate it. For package names, it's speedier for us to leave them
as they're, until someone tell us how to call them, otherwise we risk
to have to rename them several times.
Open souce projects don't often function this way, usually
they live or die by
their ability to support new development. This is why I am
very interested in
what can be done to help.Phrased another way, other people have the need to do RnD
work on GeoTools how
can we allow everyone to work together? Is it the sheer
volume of active RnD,
would laying down a roadmap help? What your time parameters?I am not saying their is not a problem, I am just wondering
how we can help.
We're running very strict with time so we have to choose the fastest way,
but I want it to be clear that this was our own fault!!!
Having said that we could have used a little more stability from GeoTools
and more coordination with GeoServer. There was a GT 2.0.x that was used
by GS 1.2.x, then you go on with GT 2.1.x (with a few API changes
between the two) and then, before GS 1.3.x was out you go on with 2.2.x.
This was a little too fast in my opinion, expecially because not all
the bugs filed for 2.1.x were fixed and now they have to be fixed in
two different versions.
Also the evolution in the Feature model and the API changes were not
very client-code-friendly.
I also think there should be much more coordination between GeoTools
and GeoServer (and uDig also) and maybe some code may stay inside GeoServer.
For example the DataEngine I explained above won't have nothing to do with
WFS and HTTP, but in a sense it will act as a service for client code,
so why not let it be inside GeoServer.
Put it another way, should GeoServer only be a Web interface upon GeoTools
or may it contain non Web functionalities???
Jody
Bye Paolo