Another MicroArchitecture production. 

A distributed cursor is a form of iterator. Also known as a split-cursor.

On a movement, the client-cursor passes a Memento to the server-cursor as a parameter. The server uses the memento to establish the absolute location of the cursor in the iterated structure before applying the movement. The new position is returned by the server to the client for use in any future movements.

Maintaining server state in the client allows the server to be stateless.

Implementing the memento as a StateObject allows it to cross any architectural boundary e.g. across a messaging system.

--------------------------------------------------------------------------------

I was playing with encapsulation boundaries in iterators. I started from a client-proxy to a normal server-side iterator. I noticed that lots of cursors tended to be instantiated on the server, leading to a lot of thrashing. To go to a fully scalable model, the server-side structures needed to be stateless. Then instead of one server-side iterator per client, one may have a smaller number, with appropriate synchronization logic. 

Since some cursor operations are relative movements, the position state had to be held somewhere.  So I put the position data in the proxy, as a Memento. This was passed as a a parameter to the server-side cursor. This is a variation on the GoF (monolithic) cursor.

So, what we have is an small architectural pattern. An element. It maps an iterator across a distribution boundary. Furthermore it does so anonymously and using a uniform interface. The cursor arrangement allows stateless server operation, providing the most scalable possible implementation. If you're paranoid you can encrypt your server keys. Versioning is supported (any state really), and it isn't too hard to cache keys to provide a position marking service. This arrangement appears in various schemes e.g. browser cookies, calculation farms etc. --RichardHenderson.