Protocols in OpenLayers suck. We have bits split out across the full range of classes, and that is a mistake. Instead, we should collect these bits. I'll start by describing the way that WFS-T works now, and how it should work.

Currently, for reading:

• Layer.WFS uses
  • Tile.WFS which uses
    • Format.WFS to read data

For writing:

• Layer.WFS uses
  • Format.WFS to write out a single transaction for all changed features

Instead of this, all of the 'read', 'write', 'commit', etc. should be in one place. We'll call this a Protocol.

A protocol has 5 methods:

• Read
• Create
• Update
• Delete
• Commit, which takes a list of features and causes them all to be committed, whatever method this takes.

For WFS-T, the 'commit' method is different, because multiple actions can be taken at once. Other protocols, like AtomPub, might have 'commit' just be a wrapper aorund multiple create/update/delete calls.

Then, we need layers to use these protocols. Right now, there are two primary ways we request vector data: Layer.GML, which is a 'load a single URL' layer, and Layer.WFS, which is a 'load data as you move around the map' Layer. Instead of these existing layers which just use formats, a new layer would be protocol based, and it would know how to request data based on the type of input: so, for example, the read method for a replacement for a GML layer would likely simply be passed the URL, without things like a bounding box. Additional protocol-level read options -- like number of features, or other paging information -- might also be found to be important, so the layer could have a readOptions option on it to pass in when reading. reload() calls would call the read() method again, but nothing else would.

A WFS-Layer replacement would do something similar, except that it would call the read() method any time the bounds of the currently loaded data did not cover the current view (most likely). This could just be an option to the previously described layer.

Then, this layer type would have a commit() method that would use its protocol to commit its features.

The protocol Commit loops through the entire feature list that is passed in, and depending on the state of the feature -- stored via feature.state and the Feature.Vector.State constants -- would decide what to do, and do it.

The layer would also have knowledge of when to call commit: for example, commit might be called any time a feature changed, or might be delayed until a manual call.

Comment (Sean): This seems like a good plan. About the protocol's commit method: would it be responsible for committing heterogeneous changes? By this I mean the case where features have been added, removed, and modified. And what would you think about using Subversion as a model for protocols?

Comment (Tim): Yeah, that was the idea with commit. Specific protocols would be responsible for serializing the individual messages (where create, update, insert, and delete are handled in separate messages). Would be good to discuss options/alternatives. This was thrown up by Chris based on a quick conversation I had with him the other week. More discussion is needed.

Comment (Tim): I've started collecting thoughts about behavior for vector layers here.