What is an elevator idiom?
I have read about REST. When I had an overview of Lift, it seems like Lift:
- maintains state on the server (Java EE application) and
- requires server affinity in a clustered environment
Raising the idea of statefullness seems different from REST and cousins. What is an elevator idiom? Why is server affinity needed? Will it become a minefield if we stray from the fixed idiom?
How would it play out (and become an advantage) in this hypothetical simultaneously editable table:
- The user is editing a cell in a row. The editor shows "sync" for this cell when the user continues editing (asynchronously) and discards this notification if the data has been synced to the store...
- Another user starts editing the document. The first editor is notified.
- The first user edits a line that the other guy sees. The other guy knows which lines are changed.
Update: dave commented on the exact reason for the server's proximity: here and here . It turns out that FourSquare, a very heavy trading site, uses this very method.
source to share
This is discussed in Lift in Action, how it happens. The main reason for state is security: an elevator relies heavily on in-memory state for security features such as GUIDs displayed by functions on page controls. Also, you'll find that frameworks that claim to be stateless and do nothing other than pure REST actually do a pretty bad job when creating a stateful environment: this usually includes a circular disable state in cookies or serializing it to a hidden form field. Both of these methods are used in popular frameworks (Rails, .NET, Play, etc.).
Also, it turns out that keeping things in memory is pretty useful, as it means that every request doesn't require re-initializing things like database connections, etc. It also allows for some very nice features like Lift Combine Support.
Hope it helps.
Tim
source to share