scala - What is Lift's state idiom? -
i have read rest. when had overview of lift, seems lift:
- maintains state in (java ee application) server and
- needs server affinity in clustered environment
lift's idea of statefullness seems distinct rest , kin. lift's state idiom? why need server affinity? become minefield if deviate fixed idiom?
how come play in (and become advantage) in hypothetical concurrently-edited spreadsheet:
- a user edits cell in row. editor shows "syncing" cell user continues editing (asynchronously), , drops notification if data has been synced backing store.
- another user starts editing document. first editor gets notified.
- the first user edits row other guy has visible. other guy knows rows changed.
an update: dave commented on exact reason server affinity: here , here. turns out foursquare, heavily trafficked site uses method.
this discussed in lift in action happens. primary reason statefulness security: lift heavily dependant on in-memory state security features function-mapped guids on page controls. in addition, you'll find frameworks claiming stateless , doing pure rest doing pretty bad job @ being stateful framework: typically involves round tripping state cookies or serialising hidden form field. both of techniques used popular frameworks (rails, .net, play etc).
moreover, turns out keeping things in memory pretty useful means each request doesn't have reinitialise things database connections , forth. allows nice features lift's comet support.
hope helps.
tim
Comments
Post a Comment