Actors in Lift

[debasish]

Dear All -

I have had a look at Lift quite some time ago. I remember referring to
this excellent post by David Pollak on the usage of actors in Lift
(http://blog.lostlake.org/index.php?/archives/59-How-lift-uses-Scala-
actors.html). Now that I am looking at the code base after quite some
time, I find lots of changes in it. e.g. the above post refers to
implementation of Session, Page, Controller etc. as Scala actors that
nicely interacts in the Request / Response cycle of Lift. But the
latest snapshot from Github indicates that the usage of actors in Lift
is now different. Is there any document or pointer that describes the
rationale of this change or explains the current usage of actors in
request / response processing ?

Thanks.
- Debasish

[David Pollak]

Howdy,

As Lift evolved and I did performance analysis, I found that the places where Actors were used were not necessary, added complexity to the code, and had adverse performance characteristics.  For example, as I added more methods to LiftSession, I found that it became increasingly difficult to choose between "methods" and "messages".  The problem became acute when Snippets and things external to LiftSession had to access LiftSession's state during the servicing of a request.  LiftSession needed public methods, but those exposed state and thus the Actor model broke down.  Yes, I could have created a "CurrentLiftSessionState" object that was exposed only to the current request via S (the thread-local state), but that seemed to be way too complex.

So, at this point, Actors are used for CometActors and to help service Comet requests (event-based actors are used to suspend the long poll.)

Does this help?

Thanks,

David

 

Thanks.
- Debasish

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[debasish]

David -

Thanks a lot for the clear explanation.

Just curious - do you think the previous implementation philosophy of
controllers, sessions and pages as actors with state changes being
done only through messages was a more FP oriented approach ? And that
the actor model broke down since Session is inherently an abstraction
that needs to be more stateful.

Thanks.
- Debasish

On Mar 4, 9:10 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote:

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[David Pollak]

On Wed, Mar 4, 2009 at 8:26 AM, debasish <ghosh.d...@gmail.com> wrote:

David -

Thanks a lot for the clear explanation.

Just curious - do you think the previous implementation philosophy of
controllers, sessions and pages as actors with state changes being
done only through messages was a more FP oriented approach ?

Actually, just the opposite. :-)

Actors and OO are twin concepts.  Actors provide state, data hiding and messaging (sound like words that come from Smalltalk) in a world where mutability is eschewed.  It turns out that Actors have their roots in Scheme and that Smalltalk has its roots in Scheme's Actor implementation (if you need a reference, I'll dig it up.)

Rarely is LiftSession state mutated directly.  With the exception of SessionVars, S (threadlocal state) holds a list of state mutations (new functions that are bound to HTML elements).  Having granular read operations on LiftSession and application of state changes accumulated in S as part of the completion of page rendering is about as close as I could get in Scala to Haskell's state monads.

 

And that
the actor model broke down since Session is inherently an abstraction
that needs to be more stateful.

The Session is an abstraction that is very, very complex and there's lots of highly granular data that needs to be exposed during the processing of a request.  This granular data is better exposed on LiftSession than via request/response messages or some proxy "thingy".

Put another way, it depends on what you mean by "state".  It would be possible to pass a LiftSession around as an explicit parameter and return a mutated LiftSession... making things feel more "functional", but this gets back to the limitations of Scala vis Haskell's state monad.

Put another way, LiftSession has very few public mutator methods.  It's mostly read-only.  Is this "state" in the same way that a JavaBean is stateful.  Now that's a debate worth having (better line up James and others.) :-)

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

[debasish]

Thanks again for the cool details. I now get it.

Thanks.
- Debasish

On Mar 4, 9:48 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote: