Hi all,
one of the key elements of a wiki style WFS is attribution, that
is the ability to identify who did a certain change.
Now, we do have a list of things to be done in order to get to attribution:
* authentication (who are you???)
* authorization (can you do that???)
* attribution (yeah, this badly digitized contour is really your fault)
At the same time we do have different layers in our service cake:
* servlet level
* wfs Transaction level
* datastore level
Well, I guess the three layers above do match those below, that is:
* authentication should be done somewhere, somewhat above the wfs
Transaction operation (think http basic authentication, since
WFS-T is not "stateful" in the sense of http session stateful).
* authorization should be handled at the wfs transaction level...
first tell me what the heck you want to modify, and I'll tell
you if you can. I imagine a service that allows the configuration
of feature type and filter based authorization, so that you
can say "Mr X can modify only on state boundary data, provided the
state is on the west coast".
Hum... this could be exploited also on reading, by adding some
"feature shaving" filters, that is, having some sensible data or
attribute that you don't want everybody to see. So you configure
a Query mixin that will be added to the user one (ok, I'm going
overboard here).
* attribution. heh, this should be done at the datastore level.
So, how do I tell the datastore that features he's writing/updating
are to be marked as "mr x" fault?
Here I see a few options:
* extend the datastore so that you specify the user id as a parameter
when you ask for a FeatureWriter (and if you don't, you get a nice
exception instead, unless someone has specified a default user id
during datastore configuration so we have something to fallback
onto).
* have the feature type contain also the user id... bleah, don't like
this one, we would have to change all features before writing,
would expose the last modifier on reading too (the feature type
is the same when you read and when you write, remember?), and
my implementation of versioning would have to perform a join
in order to gather that information (bad!)
* have attribution information be "in the air", which in Java means,
be attached to a ThreadLocal. The datastore gathers this ThreadLocal
and sets the attribution accordingly. This is the way transaction
state or hibernate session is managed by Spring, yet I'm not sure
I like it, it's not direct, visible.
What do you think? How should I manage attribution?
Cheers
Andrea