This page last changed on Feb 27, 2008 by


The basic idea is that we have two possible use cases for outside software wanting to know about changes made to a datastore in Geoserver:

  • GeoSync: A slave server is listening to a feed of changes made so that it always contains an up-to-date copy of data that may be altered at any time.
  • History Feed: An end-user application wants to show a list of recent changes made to a map.

How much do these  have in common?

Existing Proposal

One proposed mechanism for the GeoSync use case is to have GeoServer publish each transaction to an external server via the AtomPub protocol.  Each slave server would subscribe to the Atom feed and poll periodically, then interpret fields in the atom feed with pre-specified meanings.

Presumably the History Feed use case could be accomplished by simply having the client application subscribe to this same Atom feed.


Wouldn't having the feed published via Atom require polling from the slave servers?  As I understand it, the feed would contain the last N transactions, so if more than N transactions occurred within one polling interval (aside from the wasted bandwidth from all the "has anything changed? not in the last 10 minutes" requests.  Probably this could be resolved by having the server accept a query parameter like "?since=2008-01-12-12:00:00".  Option 2 would be to have the slave servers implement AtomPub directly so that changes are 'published' straight to them.

 What about security, ie; if you were syncing privileged data to other servers, the AtomPub server would need to have some means of restricting the output to ensure that the data didn't leak to nefarious third parties.

For the history feed, it would probably be useful to allow further restrictions on the output.  To provide a concrete example, I've talked with one of the Vespucci developers about what they'd have in their ideal history feed:

Interface: Simple http request, allows getting changes for entire map, or just for some set of features filtered by rules (to elaborate, the current plan for implementing per-project maps in is to maintain one featuretype with the features for all projects and an attribute saying which project they are with.  Vespucci would allow overlaying multiple maps from the set of maps a user has permission to view, we'd want the feed to be able to limit itself to "changes to features on the layers currently being viewed" or "changes to the currently viewed feature" or "changes to maps the user can view" in different contexts.  Also, a 'recent changes' feed would probably want to be limited to the last N features, and missing a few transactions would be permissible/desired.

Data: Ideally entries in the feed would contain the following information:

  • User who made the change
  • Comment if any
  • Time
  • Type of transaction
  • Values of affected features before the transaction
  • Values of affected features after the transaction 
Document generated by Confluence on May 14, 2014 23:00