Nice to see the intent to withstand little breakage for the right reason! I am +0 on lift-common. It possibly doesn't mean much, but the only reason I proposed it as an option is because most people with exposure to Java projects have encountered jakarta-common and in some sense have *-common hardwired in their brain and can relate to.
Personally, I am -1 on liftx and lift-scalax. They either don't conform to naming convention or aren't unambiguous enough. +1 for lift-util to lift-webutil. Cheers, Indrajit NB: 0. Let's use one conversation trail to converge on the name(s) please. Reduce duplications ;-) 1. It's imperative that the package for the respective classes would have to be adjusted too. net.liftweb.util._ inside lift-webutil.jar would be utterly confusing IMHO. 2. Once the package names are through, the Lift book would need to be updated too. On 30/09/09 7:09 PM, David Bernard wrote: > > But my opinion == 0, I not a lift's user, but I see lot of case where > some lift lib could be used without working on a webapp. > > On Wed, Sep 30, 2009 at 15:37, David Bernard<david.bernard...@gmail.com> > wrote: >> my salt >> (I don't like lift-common, "common of what ?" ) >> If you don't want to move actors, box... to lift-util (xml >> utilities,... aren't only for web) >> As actor and box are language "extension", I suggest lift-lang, >> lift-langplus, liftx, lift-scalax >> >> ;) >> >> /davidB >> >> On Wed, Sep 30, 2009 at 15:29, Viktor Klang<viktor.kl...@gmail.com> wrote: >>> Aye >>> +1 >>> >>> On Wed, Sep 30, 2009 at 3:27 PM, Heiko Seeberger >>> <heiko.seeber...@googlemail.com> wrote: >>>> >>>> +1 >>>> >>>> 2009/9/30 Derek Chen-Becker<dchenbec...@gmail.com> >>>>> >>>>> I would vote for naming the new module lift-common and renaming lift-util >>>>> to lift-webutil. It does mean some breakage but I think that it's a >>>>> clearer >>>>> naming. lift-util and lift-common are just too close for someone coming in >>>>> new, IMHO. >>>>> >>>>> Derek >>>>> >>>>> On Wed, Sep 30, 2009 at 5:34 AM, Jonas Bonér<jbo...@gmail.com> wrote: >>>>>> >>>>>> 2009/9/30 Josh Suereth<joshua.suer...@gmail.com>: >>>>>>> As much as I agree with your decision, it just makes me sad. I know >>>>>>> lots >>>>>>> of people that learned scala for "actors are the way of the >>>>>>> future".... I >>>>>>> think we need to push harder. Hopefully all major projects migrating >>>>>>> off >>>>>>> actors will give EPFL a wake up call? >>>>>> >>>>>> This is the reason I created Akka, to have a standard platform for >>>>>> Actors with all the things one need to write production applications. >>>>>> Akka already have 4 committers and honestly, looking at the pace EPFL >>>>>> has had with bugfixing, features etc I think they will have a very >>>>>> hard time keep up with what the market needs. I have unfortunately >>>>>> given up up the Scala Actors library. I need the things Akka >>>>>> implements now and don't have time to wait indefinitely. >>>>>> >>>>>>> >>>>>>> - Josh >>>>>>> >>>>>>> On Tue, Sep 29, 2009 at 1:41 PM, David Pollak >>>>>>> <feeder.of.the.be...@gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck >>>>>>>> <stuart.roeb...@gmail.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Apologies if I've missed something obvious but my web search hasn't >>>>>>>>> turned anything up... >>>>>>>>> >>>>>>>>> What are the Scala Actors instability issues? I'm in the process of >>>>>>>>> doing some major Scala development work and this comment raises >>>>>>>>> concerns that I'd like to understand. >>>>>>>> >>>>>>>> The issues (with the Scala Actors in general and Lift's use of them) >>>>>>>> are: >>>>>>>> >>>>>>>> Scala Actors use a custom version of Doug Leah's Fork/Join library. >>>>>>>> This >>>>>>>> was necessary for JDK 1.4 support. With JDK 1.5, the >>>>>>>> java.util.concurrent >>>>>>>> stuff should have been used. I was led to understand that this >>>>>>>> change was >>>>>>>> made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff >>>>>>>> still >>>>>>>> contains fork-join. The FJ library has a memory retention issue >>>>>>>> where it >>>>>>>> trades memory for non-locking performance and, with many threads in a >>>>>>>> thread-pool, this leads to out of memory issues. >>>>>>>> The Scala Actor code is very brittle. >>>>>>>> >>>>>>>> See >>>>>>>> http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html >>>>>>>> The code has not been materially refactored, which means that even >>>>>>>> in 2.8, >>>>>>>> there will be significant potential problems with the Actors. Those >>>>>>>> potential problems have manifest themselves as real problems in >>>>>>>> 2.7.x. I >>>>>>>> have spent in aggregate nearly 3 weeks of my time since November 2008 >>>>>>>> working around the defects in the Actor library. It's easier to have >>>>>>>> our >>>>>>>> own Actors (the current Actor library is about 2 days of work on my >>>>>>>> part and >>>>>>>> the refactoring of Lift to work with the existing Actor library is >>>>>>>> another 2 >>>>>>>> days of work.) >>>>>>>> EPFL has been generally slow to respond to bug reports. I am very >>>>>>>> frustrated and quite frankly tired of having to cajole EPFL into >>>>>>>> responding >>>>>>>> to defects in one of the premier Scala libraries. >>>>>>>> >>>>>>>> I would strongly suggest that you look at Akka. It's got a better >>>>>>>> view >>>>>>>> and implementation of Actors than does the standard Scala >>>>>>>> distribution. Akka >>>>>>>> includes support for distributed actors, etc. >>>>>>>> Hope this helps. >>>>>>>> >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> On Sep 29, 3:30 am, David Pollak<feeder.of.the.be...@gmail.com> >>>>>>>>> wrote: >>>>>>>>>> Folks, >>>>>>>>>> >>>>>>>>>> Given the continued instability of Scala Actors, I've decided to >>>>>>>>>> remove >>>>>>>>>> them >>>>>>>>>> from Lift. >>>>>>>>>> >>>>>>>>>> Specifically, I'm migrating CometActors to sit on top of Lift's >>>>>>>>>> Actors. >>>>>>>>>> But, you'll also be able to use Akka Actors to power Lift's >>>>>>>>>> CometActors. >>>>>>>>>> Specifically, I'm working with Jonas to make sure that we share a >>>>>>>>>> common >>>>>>>>>> interface to Actors. >>>>>>>>>> >>>>>>>>>> I've gotten Lift nearly completely migrated over to Lift's Actors >>>>>>>>>> on >>>>>>>>>> the >>>>>>>>>> dpp_wip_actorize branch. >>>>>>>>>> Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize >>>>>>>>>> >>>>>>>>>> There will be some breaking changes to your applications. >>>>>>>>>> Specifically: >>>>>>>>>> >>>>>>>>>> - Box will be moved to a new package, net.liftweb.base (this is >>>>>>>>>> where the >>>>>>>>>> interface for Actors will live as well) >>>>>>>>>> - If you make any assumptions about your CometActors being >>>>>>>>>> Scala >>>>>>>>>> Actors >>>>>>>>>> (e.g., using linking), you will have to rewrite this code >>>>>>>>>> - Some methods in Lift that currently take Scala Actors as >>>>>>>>>> parameters >>>>>>>>>> will take Lift Actors (e.g., ActorPing) >>>>>>>>>> >>>>>>>>>> There will be a parallel Maven repository with the new Lift Actor >>>>>>>>>> stuff >>>>>>>>>> in >>>>>>>>>> it so you will be able to build you apps against the new code >>>>>>>>>> before >>>>>>>>>> the >>>>>>>>>> official switch-over. >>>>>>>>>> >>>>>>>>>> Milestone 6 (which should be out next week) will be based on the >>>>>>>>>> existing >>>>>>>>>> Actor model. After we get feedback from the community about the >>>>>>>>>> new >>>>>>>>>> Actor >>>>>>>>>> stuff, we will switch -SNAPSHOT over to the new Actor stuff. >>>>>>>>>> >>>>>>>>>> Questions, thoughts, or comments? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lift, the simply functional web frameworkhttp://liftweb.net >>>>>>>>>> Beginning Scalahttp://www.apress.com/book/view/1430219890 >>>>>>>>>> Follow me:http://twitter.com/dpp >>>>>>>>>> Surf the harmonics >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jonas Bonér >>>>>> >>>>>> twitter: @jboner >>>>>> blog: http://jonasboner.com >>>>>> work: http://crisp.se >>>>>> work: http://scalablesolutions.se >>>>>> code: http://github.com/jboner >>>>>> code: http://akkasource.org >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Heiko Seeberger >>>> >>>> My job: weiglewilczek.com >>>> My blog: heikoseeberger.name >>>> Follow me: twitter.com/hseeberger >>>> OSGi on Scala: scalamodules.org >>>> Lift, the simply functional web framework: liftweb.net >>>> >>>> >>> >>> >>> >>> -- >>> Viktor Klang >>> >>> Blog: klangism.blogspot.com >>> Twttr: viktorklang >>> >>> Lift Committer - liftweb.com >>> AKKA Committer - akkasource.org >>> Cassidy - github.com/viktorklang/Cassidy.git >>> SoftPub founder: http://groups.google.com/group/softpub >>> >>>>> >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
