Chris Holmes ha scritto:
So at TOPP we're working on a collaborative editing environment built on the new versioning wfs stuff (http://docs.codehaus.org/display/GEOS/Versioning+WFS). A demo is up at: http://artois.openplans.org/annotation_demo/
Right now we're not doing a ton with the versioning, but it is being used to track who makes edits and comments, and when they happened. We want to display this information in the pop-up. Unfortunately right now that involves two requests, a GetFeature and a GetLog. And that's just for one pop-up, for multiple ones you'd either do a GetLog on each pop-up, or else the client would have to match up features and their logs.
It seems like displaying the user and time editing will be pretty common in a collaborative environment, if we have that information.
So I'm wondering if we should make use of VersionedFeatureCollection for
this? I know we had the concept of that, which mostly was just to
include an attribute of what version the collection is at. I wonder if we might consider having timeCreated, timeUpdated, createdBy and lastUpdatedBy as sort of extra attributes? Maybe they would automatically be returned with a GetVersionedFeature request? Or that at least with that kind of request the client could ask for them as extra params in propertyname?
These informations would be different for each feature, so you're
right they have to be expressed at the level of each feature.
If we used properties that would mean we have a different kind of feature type thought, that is, DescribeFeatureType would have to
return them, and that would mean having those properties resident in
the feature type (that is, always there).
We would have some ripercussions on the implementation, since
gt2 datastores cannot do joins I would have to create a permanent
view on the db and use the view for reading and the original table for writing. This would bring up some naming issues, in that I need to
give views names that cannot conflict with regular tables, and also
the original tables would be forbidden to have those columns (since
we're going to create a new feature type that has both the columns
of the original table and the ones of changesets).
All in all, I guess the easiest way is to have those extra parameters
always in, that won't disrupt the non versioning client (would just
give them some extra properties that they can shave off). This leaves
a problem of how to deal with updates and creations, since those
extra properties would have to be shaved off (they are not updatable,
yet in xml schema there is no notion of "read only" attribute).
There would also be a performance price to pay, since we would be
doing a join even for regular reads (I can try to optimize the join
out if none of the extra columns is used).
Time wise, I guess that would require at least one day of coding
(maybe more) since I would have to split out the read and write parts of the datastore. The nice thing is that by working like this I would
not need to touch the upper levels at all. And oh, the database structure would become non backwards compatible so anybody using
versioning would have to start from scratch (yes, I could add some
code that converts the database structure and adds the necessary views,
just not sure we want to start adding this kind of extra code when
the datastore is still in its infancy and not widely used).
Opinions?
Cheers
Andrea