Thanks again for the cool details. I now get it.
Thanks.
- Debasish
On Mar 4, 9:48 pm, David Pollak wrote:
> On Wed, Mar 4, 2009 at 8:26 AM, debasish 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.) :-)
>
> Thanks,
>
> David
>
>
>
>
>
> > Thanks.
> > - Debasish
>
> > On Mar 4, 9:10 pm, David Pollak wrote:
> > > On Wed, Mar 4, 2009 at 7:59 AM, debasish
> > wrote:
>
> > > > 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 ?
>
> > > 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
>
> > > --
> > >
