[Lift] Re: Actors in Lift
On Wed, Mar 4, 2009 at 7:59 AM, debasish ghosh.debas...@gmail.com 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 -- 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Actors in Lift
On Wed, Mar 4, 2009 at 8:26 AM, debasish ghosh.debas...@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.) :-) Thanks, David Thanks. - Debasish On Mar 4, 9:10 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Mar 4, 2009 at 7:59 AM, debasish ghosh.debas...@gmail.com 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 -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Actors in Lift
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: On Wed, Mar 4, 2009 at 8:26 AM, debasish ghosh.debas...@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.) :-) Thanks, David Thanks. - Debasish On Mar 4, 9:10 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Mar 4, 2009 at 7:59 AM, debasish ghosh.debas...@gmail.com 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 -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
