Re: [Lift] Re: Where are the dragons hiding?
On Mon, Nov 23, 2009 at 7:24 AM, Jeppe Nejsum Madsen wrote: > Marius writes: > > > It should be just fine. > > > > You can tell lift to not use Ajax or any JS at all. There are some > > flags in LiftRules to do that. > > > > LiftRules.setAutoIncludeComet = false; > > LiftRules.setAutoIncludeAjax = false; > > > > > > Besides that just don't use JS in your markup or don't use Lift's ajax > > stuff. > > Even if you don't explicitly use any Ajax, I believe Lift will store > callback mappings in the session? How does Lift's GC work if there's no > JS support? > The functions are retained for the duration of the session. This will not likely cause an issue on mobiles and the usage is not likely to produce a lot of pages/forms during a given session. > > /Jeppe > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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=. > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
Re: [Lift] Re: Where are the dragons hiding?
Marius writes: > It should be just fine. > > You can tell lift to not use Ajax or any JS at all. There are some > flags in LiftRules to do that. > > LiftRules.setAutoIncludeComet = false; > LiftRules.setAutoIncludeAjax = false; > > > Besides that just don't use JS in your markup or don't use Lift's ajax > stuff. Even if you don't explicitly use any Ajax, I believe Lift will store callback mappings in the session? How does Lift's GC work if there's no JS support? /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
[Lift] Re: Where are the dragons hiding?
It should be just fine. You can tell lift to not use Ajax or any JS at all. There are some flags in LiftRules to do that. LiftRules.setAutoIncludeComet = false; LiftRules.setAutoIncludeAjax = false; Besides that just don't use JS in your markup or don't use Lift's ajax stuff. Lift works with no cookies. Turning off cookies from container would automatically make Lift to use url-rewriting and put jsessionid in urls. You should be able to use XHTML MP with no problems. Br's, Marius On Nov 20, 6:28 am, ngocdaothanh wrote: > Is Lift suitable for web for mobiles? > > Generally web for mobiles (especially in Japan) has some > characteristics: > * No JavaScript support > * No cookie support > * Non standard HTML tags > > Thanks > > > I think this thread contains the key dragons in Lift. Basically, it boils > > down to: Lift is highly stateful... that has its pluses and minuses. We're > > working on mitigating the minuses (session replication and persistence). -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
[Lift] Re: Where are the dragons hiding?
Is Lift suitable for web for mobiles? Generally web for mobiles (especially in Japan) has some characteristics: * No JavaScript support * No cookie support * Non standard HTML tags Thanks > I think this thread contains the key dragons in Lift. Basically, it boils > down to: Lift is highly stateful... that has its pluses and minuses. We're > working on mitigating the minuses (session replication and persistence). -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
[Lift] Re: Where are the dragons hiding?
On Nov 19, 12:37 am, David Pollak wrote: > But one of the key things to keep in mind regarding Lift is how we as a > community handle problems. One of the biggest, nastiest bugs in Lift-land > crept into the code in the last few > days:http://groups.google.com/group/liftweb/browse_thread/thread/558280f51 > Sessions were getting destroyed seemingly randomly. Please look at how the > problem was dealt with. There will be bugs in Lift in the future. You can > expect that they will be dealt with in the future in the same way. What you > will hear from the Lift developers is that we stand behind Lift and when > there are problems, we stand behind fixing them. In terms of Scala the > language, EPFL has a very similar attitude. We will do what it takes to > support the folks who bet their careers and companies on Lift right on down > to the JVM. Good to know - thanks David. I'm sure that I will have reason to call on that support, so thanks in advance :-) paul.butcher->msgCount++ -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
Re: [Lift] Re: Where are the dragons hiding?
Paul, I think this thread contains the key dragons in Lift. Basically, it boils down to: Lift is highly stateful... that has its pluses and minuses. We're working on mitigating the minuses (session replication and persistence). But one of the key things to keep in mind regarding Lift is how we as a community handle problems. One of the biggest, nastiest bugs in Lift-land crept into the code in the last few days: http://groups.google.com/group/liftweb/browse_thread/thread/558280f51666972f/0291e1224f0f0ce8?hl=en#0291e1224f0f0ce8. Sessions were getting destroyed seemingly randomly. Please look at how the problem was dealt with. There will be bugs in Lift in the future. You can expect that they will be dealt with in the future in the same way. What you will hear from the Lift developers is that we stand behind Lift and when there are problems, we stand behind fixing them. In terms of Scala the language, EPFL has a very similar attitude. We will do what it takes to support the folks who bet their careers and companies on Lift right on down to the JVM. Thanks, David On Wed, Nov 18, 2009 at 3:43 PM, Paul Butcher wrote: > Thanks everyone - that's exactly the kind of information that I was > looking for. > > Now all I need to do is persuade my colleagues that selecting a young > technology (again) is a good idea ;-) > > Thanks again, > > paul.butcher->msgCount++ > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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=. > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
[Lift] Re: Where are the dragons hiding?
Thanks everyone - that's exactly the kind of information that I was looking for. Now all I need to do is persuade my colleagues that selecting a young technology (again) is a good idea ;-) Thanks again, paul.butcher->msgCount++ -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
Re: [Lift] Re: Where are the dragons hiding?
Hi, Marius wrote: > On Nov 18, 6:31 pm, Paul Butcher wrote: > >> I'm seriously considering Lift for a new project. I know what the >> benefits of Scala and Lift are (that's why I'm seriously considering >> this as a route forwards :-) What I'm wondering is whether there are >> any lurking nasties that I should be aware of (so that I can avoid >> learning about them the hard way). >> > > Not sure if there is any. One thing though Lift's session state is > kept in memory and not serialized in the DB. Session serialization is > a bit tricky since we keep the bound functions on the session state. > Those functions are in many cases anonymous function that may hold > other references which are not serializable. Even if everything is > serializable using Java serialization is likely suboptimal. But > keeping the sessions in memory and have a session affinity load > balancing is a very good choice from performance perspective. > > There are people playing around with Terracotta (http://www.terracotta.org/web/display/orgsite/Platform) and Lift. There seems to be some success regarding actors running on a cluster. No idea if Terracotta plays well with Lift session handling. There's only an unanswered post in the ML archive on that. Regards, Eros -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Where are the dragons hiding?
See this thread: http://groups.google.com/group/liftweb/browse_thread/thread/4a174ecf34873967/ In which we discuss how certain queries generated by Mapper perform very poorly on MySQL. Certainly this problem could be addressed, but until it is using Mapper with MySQL will be problematic. -harryh -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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: Where are the dragons hiding?
If I may .. this statement is confusing leading to incorrect interpretation. Lift works with MySQL as ANY Java application. Harry may have referred to Lift's Mapper framework which for MySql may be some problems that I'm not aware of. But if MySQL becomes critical for you I'm sure things can be prioritized. On Nov 18, 8:23 pm, cody koeninger wrote: > On Nov 18, 11:32 am, harryh wrote: > > > - Don't use Lift with MySQL, they don't play nicely. Use PostgreSQL > > Can you elaborate? -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
[Lift] Re: Where are the dragons hiding?
On Nov 18, 11:32 am, harryh wrote: > - Don't use Lift with MySQL, they don't play nicely. Use PostgreSQL > Can you elaborate? -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
[Lift] Re: Where are the dragons hiding?
Some issues I've run into along the way that you should be aware of (in no particular order): - Don't use Lift with MySQL, they don't play nicely. Use PostgreSQL - Be away that Lift webservers are stateful, so if you have more than 1 of them serving the same application you will need sticky sessions. It can take some care to get this set up right. - Take care to serve items that don't require session state from the "stateless dispatch table." Further, things like static images, css, and js files shouldn't be served by lift at all. I as running into problems with too many single use sessions being created (from things like web crawlers) and it causing CPU spike when the GC got overwhelmed. -harryh -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
[Lift] Re: Where are the dragons hiding?
On Nov 18, 6:31 pm, Paul Butcher wrote: > I'm seriously considering Lift for a new project. I know what the > benefits of Scala and Lift are (that's why I'm seriously considering > this as a route forwards :-) What I'm wondering is whether there are > any lurking nasties that I should be aware of (so that I can avoid > learning about them the hard way). Not sure if there is any. One thing though Lift's session state is kept in memory and not serialized in the DB. Session serialization is a bit tricky since we keep the bound functions on the session state. Those functions are in many cases anonymous function that may hold other references which are not serializable. Even if everything is serializable using Java serialization is likely suboptimal. But keeping the sessions in memory and have a session affinity load balancing is a very good choice from performance perspective. > > Some background: Until recently I was CTO of Texperts, a UK startup. > We moved to using Ruby on Rails shortly after version 1.0 was released > (i.e. when it was at just about the same level of maturity as Lift is > now). Our experience was mostly very good - the major issues we had > were deployment problems arising from the fact that Ruby's threads > aren't really threads. > > I'm now looking at a new project, a significant chunk of which will be > a webservice likely to be installed within a mobile network operator's > infrastructure. That fact is a powerful argument for writing it in > Java (MNOs all know how to run big Java app servers) but the very > thought of being stuck writing Java for the foreseeable future makes > me break out in hives :-) > > So I'm considering Scala and Lift. In particular, I'm considering the > tradeoffs of Lift versus something like Spring+Scala. IMHO there is no tradeoff. Scala's nature tremendously facilitates things using functional composition and Spring's MVC/AOP etc. doesn;t really bring you much benefits. Not to mention that Lift's templating mechanism is really great. > > I'm not too worried about problems that might bite us while we're > developing the service. I hope that we're smart enough, and the Lift > community is helpful enough, that we should be able to work our way > through those kinds of problem (although a heads-up would still be > welcome). I'd say that this is a safe bet. > > What I *am* worried about are problems that might bite us when we come > to install the service at an MNO. Having said "don't worry - it'll run > on your app server just fine", is there anything that might prove > problematic if we choose Lift? In essence Lift start as a plain servlet filter so I wouldn't expect any incompatibilities. But I'd recommend lightweight containers with nice non-blocking IO. Jetty looks to be a good choice. Non blocking IO support is particularly helpful when using Comet and Lift has a built in mechanism for that. Is there anything we can do ahead of > time to head this kind of problem off at the pass? How should we test > to minimise the chance of problems? Would choosing Spring+Scala > decrease any of these risks? I don't see what Spring brings and Lift doesn't and how it would minimize risks. > > Very many thanks in advance for any help or advice you can offer, > > paul.butcher->msgCount++ -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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=.
