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
-~----------~----~----~----~------~----~------~--~---

Reply via email to