Google is your friend:
http://gaydenko.com/scala/tiscaf/httpd/
http://code.google.com/p/scala-http/

On Fri, Jan 16, 2009 at 6:28 PM, Thomas Sant Ana <mailleux@gmail.com> wrote:

I'm working on my hobby project, it's a swing application mostly focused for windows. I finde the scala Library big enough for distribution.


I need to be able to do some HTML scrapping or capturing from a site. I managed to create a simple Firefox Extension that grabs the information I want and sends it of in an AJAX post. In order to have this captured in my application I need some sort of embedded HTTP Sever. I looked around and found Jetty. But this is a 24MB package that includes a lot more than what I need. I fell unconfortable with adding 24MB of depencency just to capture some HTML from a site.

As an alternative I create my own NanoHTTPServer (nano as small and incomplete implementation of HTTP/1.1 protocol). It allows me to process the data, and I even use some Scala pattern matching on Request's and what not. It works ok, but I have been wondering if I'm not reinventing the wheel here.

I want to know if there is a small Java HTTP Server that allows me to get POST request and maybe some GET and pass them on to some Scala code. I know some people are working on Jetty and Lift, and I wonder if there is a way to tear only the HTTP server part of Jetty and have it replace my limited implementation? Any alternative?

Thomas

Jetty can be easily embedded, requiring only 900k or so. Its also
thorouhly tested:

http://docs.codehaus.org/display/JETTY/Embedding+Jetty

I'd recommend using Jetty as it has a lot of testing behind it. Its
fast, small and stable.

On 1/17/09, Thomas Sant Ana wrote:
> I'm working on my hobby project, it's a swing application mostly focused for
> windows. I finde the scala Library big enough for distribution.
>
>
> I need to be able to do some HTML scrapping or capturing from a site. I
> managed to create a simple Firefox Extension that grabs the information I
> want and sends it of in an AJAX post. In order to have this captured in my
> application I need some sort of embedded HTTP Sever. I looked around and
> found Jetty. But this is a 24MB package that includes a lot more than what I
> need. I fell unconfortable with adding 24MB of depencency just to capture
> some HTML from a site.
>
> As an alternative I create my own NanoHTTPServer (nano as small and
> incomplete implementation of HTTP/1.1 protocol). It allows me to process the
> data, and I even use some Scala pattern matching on Request's and what not.
> It works ok, but I have been wondering if I'm not reinventing the wheel
> here.
>
> I want to know if there is a small Java HTTP Server that allows me to get
> POST request and maybe some GET and pass them on to some Scala code. I know
> some people are working on Jetty and Lift, and I wonder if there is a way to
> tear only the HTTP server part of Jetty and have it replace my limited
> implementation? Any alternative?
>
> Thomas
>

Try http://winstone.sf.net
I am using it with pretty good results.

Thomas Sant Ana wrote:

> I'm working on my hobby project, it's a swing application mostly focused
> for windows. I finde the scala Library big enough for distribution.
>
>
> I need to be able to do some HTML scrapping or capturing from a site. I
> managed to create a simple Firefox Extension that grabs the information I
> want and sends it of in an AJAX post. In order to have this captured in my
> application I need some sort of embedded HTTP Sever. I looked around and
> found Jetty. But this is a 24MB package that includes a lot more than what
> I need. I fell unconfortable with adding 24MB of depencency just to
> capture some HTML from a site.
>
> As an alternative I create my own NanoHTTPServer (nano as small and
> incomplete implementation of HTTP/1.1 protocol). It allows me to process
> the data, and I even use some Scala pattern matching on Request's and what
> not. It works ok, but I have been wondering if I'm not reinventing the
> wheel here.
>
> I want to know if there is a small Java HTTP Server that allows me to get
> POST request and maybe some GET and pass them on to some Scala code. I
> know some people are working on Jetty and Lift, and I wonder if there is a
> way to tear only the HTTP server part of Jetty and have it replace my
> limited implementation? Any alternative?
>
> Thomas

On Sat, Jan 17, 2009 at 6:05 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

> wrote:

..8ex; padding-left: 1ex;"> Jetty can be easily embedded, requiring only 900k or so. Its also
thorouhly tested:

http://docs.codehaus.org/display/JETTY/Embedding+Jetty

I'd recommend using Jetty as it has a lot of testing behind it.  Its
fast, small and stable.

I did some testing and yes it works ok, and is not that bid. The Jetty package included a lot more than the base libraries. Now time to learn how to handle these servlets :)

Thanks.

If your doing anything non-trivial with servlets and scala, your best bet
would be to use Lift...

On 17/01/2009 21:15, "Thomas Sant Ana" wrote:

>
> I did some testing and yes it works ok, and is not that bid. The Jetty package
> included a lot more than the base libraries. Now time to learn how to handle
> these servlets :)
>
> Thanks.

> If your doing anything non-trivial with servlets and scala, your best bet
> would be to use Lift...

I don't really agree to that statement...

+1 for Jetty

On Sat, Jan 17, 2009 at 11:05, Chris Twiner wrote:
> Jetty can be easily embedded, requiring only 900k or so. Its also
> thorouhly tested:
>
> http://docs.codehaus.org/display/JETTY/Embedding+Jetty
>
> I'd recommend using Jetty as it has a lot of testing behind it. Its
> fast, small and stable.
>
> On 1/17/09, Thomas Sant Ana wrote:
>> I'm working on my hobby project, it's a swing application mostly focused for
>> windows. I finde the scala Library big enough for distribution.
>>
>>
>> I need to be able to do some HTML scrapping or capturing from a site. I
>> managed to create a simple Firefox Extension that grabs the information I
>> want and sends it of in an AJAX post. In order to have this captured in my
>> application I need some sort of embedded HTTP Sever. I looked around and
>> found Jetty. But this is a 24MB package that includes a lot more than what I
>> need. I fell unconfortable with adding 24MB of depencency just to capture
>> some HTML from a site.
>>
>> As an alternative I create my own NanoHTTPServer (nano as small and
>> incomplete implementation of HTTP/1.1 protocol). It allows me to process the
>> data, and I even use some Scala pattern matching on Request's and what not.
>> It works ok, but I have been wondering if I'm not reinventing the wheel
>> here.
>>
>> I want to know if there is a small Java HTTP Server that allows me to get
>> POST request and maybe some GET and pass them on to some Scala code. I know
>> some people are working on Jetty and Lift, and I wonder if there is a way to
>> tear only the HTTP server part of Jetty and have it replace my limited
>> implementation? Any alternative?
>>
>> Thomas
>>
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1

Jan Kriesten wrote:
>
>> If your doing anything non-trivial with servlets and scala, your
>> best bet would be to use Lift...
>
> I don't really agree to that statement...
>
>
>

- --
Tony Morris
http://tmorris.net/

S, K and I ought to be enough for anybody.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJdDFNmnpgrYe6r60RAj6HAJ9bkIh2k0RmSFSvn+AfD0vy4Ol+9wCeKDHC
0q4PleFQ421y0dlJzSVnE34=
=Q5k+
-----END PGP SIGNATURE-----

On Sun, Jan 18, 2009 at 10:50 PM, Jan Kriesten <kriesten@mail.footprint.de> wrote:

> If your doing anything non-trivial with servlets and scala, your best bet
> would be to use Lift...

I don't really agree to that statement...

Why not?  What are the problems and/or deficiencies you see with Lift other than being too large (with its dependencies for this project)?

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On 1/19/09, David Pollak wrote:
>
>
> On Sun, Jan 18, 2009 at 10:50 PM, Jan Kriesten
> wrote:
> >
> >
> >
> > > If your doing anything non-trivial with servlets and scala, your best
> bet
> > > would be to use Lift...
> >
> > I don't really agree to that statement...
> >
> >
> Why not? What are the problems and/or deficiencies you see with Lift other
> than being too large (with its dependencies for this project)?
>

I personally would disagree with that statement without knowing what
else is required. Non-trivial is a huge scope and the rest of the
statement doesn't really reduce in any direction either.

Lift is a fantastic achievement, both techinically and from a
community perspective. This doesn't however imply that anything that
involves servlets and scala that has any form of complexity should use
Lift.

If this kind of statement were true we wouldn't have a myriad of
frameworks in java land covering all aspects of http based
communication on the server side and all the people using them.

On Mon, Jan 19, 2009 at 5:11 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

On 1/19/09, David Pollak <feeder.of.the.bears@gmail.com> wrote:
>
>
> On Sun, Jan 18, 2009 at 10:50 PM, Jan Kriesten <kriesten@mail.footprint.de>
> wrote:
> >
> >
> >
> > > If your doing anything non-trivial with servlets and scala, your best
> bet
> > > would be to use Lift...
> >
> > I don't really agree to that statement...
> >
> >
> Why not?  What are the problems and/or deficiencies you see with Lift other
> than being too large (with its dependencies for this project)?
>


If this kind of statement were true we wouldn't have a myriad of
frameworks in java land covering all aspects of http based
communication on the server side and all the people using them.

Once again, why?  What is the deficiency in Lift, not the generic "nothing can cover all that ground", that leads to the statement that Lift cannot satisfy the requirements for this project?
Lift provides concise and high performance ways to intercept low-level HTTP requests and generate responses:

LiftRules.dispatch.prepend {
  case Req("api" :: "message" :: id :: Nil, _, GetRequest) => XmlResponse(<message>{id}</message>)
  case r @ Req("api" :: "message" :: id :: Nil, _, PutRequest) if r.xml.isDefined => saveMessage(id, r.xml); PlainResponse("added")
}

At the other end of the web app spectrum, Lift provides the most powerful Comet and Ajax support of any web framework, and once again, the code is very concise.  Here's a clock that updates the browser every 10 seconds with the latest time:

class Clock extends CometActor {
  ActorPing.schedule(this, Tick, 10 seconds) // schedule a ping every 10 seconds so we redraw

  def render = <span>{timeNow}</span>

  override def lowPriority = {
    case Tick =>
    reRender(false)
    ActorPing.schedule(this, Tick, 10 seconds) // schedule an update in 10 seconds
  }
}

The only view code that's required to insert the clock on the page is:

<lift:comet type="Clock"/>

Most everything in Lift between servicing the low-level HTTP requests to having live components on the page is just as simple, elegant, and powerful.  When we find places for improvement, we improve Lift.
So, my question is partially requirements gathering.  You and Jan made statements that Lift does not satisfy the needs of this project.  I'd like to understand the specifics of why so we can improve Lift.
This post is also meant to nip in the bud so statements that people have made about Lift's unsuitability for building web services because it has too much other stuff in it (note the simplicity that we can build a web service above.)
On a broader note, I've been building Java-based web applications since 1996.  I ran the first large-scale deployment of WebLogic, back when WebLogic was 6 people.  I've developed one many of the common web framework tools in Java and Ruby.  I've developed alternative tools over the years because by and large the existing tools (with the exception of Rails, Django, and TurboGears) are unbelievably bad.
So, yes, there are a ton of bad Java tools out there that provide a patch-work of functionality to service HTTP requests.  The reason that there are so many is that the designs of these tools is by and large bad.  Struts is an unmitigated piece of junk.  JSF is not much better.  And these are the leading contenders for front-end development.
So, please help me with specifics so we can improve Lift.
Thanks,
David
--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

> If this kind of statement were true we wouldn't have a myriad of
> frameworks in java land covering all aspects of http based
> communication on the server side and all the people using them.

Full ack. I have tried a couple of frameworks and all have deficiencies - some
more, some less.

You have achieved quite much in your development with Lift - though some things
in it make me quite uncomfortable if I had to base my stuff on it:

- Documentation

Surely could be improved. ;-) Some of my points below may be just by lack of
better knowledge / documentation.

- Separation of concerns

I really have a hard time understanding why the HTML should be within my code
(or vice versa if you want). Maybe I'm just working differently - but we have
designers producing the html and they definitly shouldn't edit any scala files.

There is a horror-example to me on your wiki ("HowTo create simple controls"):
Mixing XML/HTML, Scala _and_ Javascript. That's really an example to me how
things shouldn't be done.

Also, localization of entire components/pages is really a challenge this way.

- Lift isn't really component-oriented

Despite being able to use something like 'widgets', Lift doesn't really support
components. That is, writing modules, where css/localization can just be jared
independently from a project and dropped in when needed.

- General things

Web-Development isn't a question about being able to handle low-level
HTTP-requests and -responses or Comet support (the latter is overrated IMHO,
anyway). Scalability is done in the servlet-container layer, so mostly I just
deal with application logic and layout. Typically, I need to develop an
application which will reside in a servlet environment and many times even
Apache is in front, too. So where's the sense to have all that low-level stuff?

A web-framework has to support fast, collective development (that doesn't
include only Scala developers but also Java + HTML). It has to provide clear
interfaces how to attach a layer for business logic and
authentication/authorization. And it should be possible to create and reuse
components easy.

Best regards, --- Jan.

On Mon, Jan 19, 2009 at 6:35 AM, Jan Kriesten <kriesten@mail.footprint.de> wrote:

> If this kind of statement were true we wouldn't have a myriad of
> frameworks in java land covering all aspects of http based
> communication on the server side and all the people using them.

Full ack. I have tried a couple of frameworks and all have deficiencies - some
more, some less.

You have achieved quite much in your development with Lift - though some things
in it make me quite uncomfortable if I had to base my stuff on it:

- Documentation

Surely could be improved. ;-) Some of my points below may be just by lack of
better knowledge / documentation.

Yep.  It's a priority right now.  All but 3 of the Lift committers are focused on documentation in preparation for the 1.0 release. 

- Separation of concerns

I really have a hard time understanding why the HTML should be within my code
(or vice versa if you want). Maybe I'm just working differently - but we have
designers producing the html and they definitly shouldn't edit any scala files.

There is a horror-example to me on your wiki ("HowTo create simple controls"):
Mixing XML/HTML, Scala _and_ Javascript. That's really an example to me how
things shouldn't be done.

You cannot put logic code in your view.
You can put view code in your Scala, but you do not need to.  You can bind all the dynamic pieces of your page content in such a way that no HTML lives in Scala code.  It takes some discipline, but it is no more difficult than keeping HTML out of Java code.  

Also, localization of entire components/pages is really a challenge this way.

Actually, Lift localization is very easy.  If you want to localize a file, just name it correctly:i..  If you want to localize a file, just name it correctly:index.html (default) index_en.html (English)index_es.html (Spanish)etc.
If there are strings in your Scala code that cannot be localized: ??("String") will look up the string the localization table.
There are other localization facilities.
Please see: http://demo.liftweb.net/lang 

- Lift isn't really component-oriented

Despite being able to use something like 'widgets', Lift doesn't really support
components. That is, writing modules, where css/localization can just be jared
independently from a project and dropped in when needed.

This is by and large not correct.
Lift supports Java resources for localization, so any resources available as part of the Java localization mechanism are available in Lift.
CSS and HTML must be part of the WAR file or in some other way accessible to the web application.  I don't know how one would drop of JAR file into a place in an app server outside the WAR file and have it accessible to the web app.  

- General things

Web-Development isn't a question about being able to handle low-level
HTTP-requests and -responses or Comet support (the latter is overrated IMHO,
anyway). Scalability is done in the servlet-container layer, so mostly I just
deal with application logic and layout. Typically, I need to develop an
application which will reside in a servlet environment and many times even
Apache is in front, too. So where's the sense to have all that low-level stuff?

If you don't want it, you don't have to worry about it.  If you just want to render HTML pages, Lift is great at that and you need not worry about Lift's support for lower level construct.  On the other hand, we don't know the requirements for the Swing app and it may be that the app is serving some sort of REST api.  In either case, Lift can handle things.  

A web-framework has to support fast, collective development (that doesn't
include only Scala developers but also Java + HTML).

Productivity on Lift apps in my experience is better than anything in Java-land and as good as or better than any other than Rails or the other highly productive web frameworks.  Yes, it takes an investment of 4-6 months until a Lift developers is fully productive, but that's similar to the learning curve in Rails.  My experience with Struts developers is that it takes 2-4 years to transition from Junior to Senior developer.
Lift does support the separation of concerns.  I regularly use a Ukranian designer on my projects.  She's strong in HTML and CSS and just has to know how to type "mvn jetty:run" to be able to test the designs in the Lift app.  

It has to provide clear
interfaces how to attach a layer for business logic

Lift allows you to have significant separation between business logic and presentation.  My experience is that these layers are false and rigidly enforcing them is bad for productivity and stability.  I managed a Java project with a code base of about 700,000 LoC for an insurance company.  When we had the 4 or 5 layers between the data model and the HTML model, very little code got written and most of the time was spent arguing about interfaces.  Further, by the time a field made it from the data tier to the presentation tier, it had lost its semantic meaning... was it a name, an address, or a Taxpayer ID?  That led to all kinds of bugs because Strings are not type-safe... they're collections of characters and can be misused very easily.  For more, see http://blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-with-the-bytes.html
So, yes, Lift tries to keep the meaning with the bytes... tries to push type-safe data structures out as close as possible to the ... tries to push type-safe data structures out as close as possible to the presentation layer.  Some people see this as bad.  My experience is that it avoids a lot of defects and allows teams to work faster.  

and
authentication/authorization.

Which Lift has excellent support for.  Lift's SiteMap provides better, more uniform, and more tightly integrated access control than anything else out there.  

And it should be possible to create and reuse
components easy.

Can you describe what you mean by components?  Can you give examples of reuse across projects?
Thanks,
David

 

Best regards, --- Jan.

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On 1/19/09, David Pollak wrote:
>

> So, my question is partially requirements gathering. You and Jan made
> statements that Lift does not satisfy the needs of this project. I'd like
> to understand the specifics of why so we can improve Lift.
>

This is the exact point from my perspective. I appreciate that Lift
is a powerful hammer but not every problem requires one.

Axis, Muse, Xfire, birt and other tools handle different problem sets.
Is your arguement really that instead of using tools more appropriate
for a given problem that we should use Lift or at least report why it
can't be used?

> This post is also meant to nip in the bud so statements that people have
> made about Lift's unsuitability for building web services because it has too
> much other stuff in it (note the simplicity that we can build a web service
> above.)

I made no such claim, niether did Jan for that matter. If I hadn't
seen plenty of evidence to the contrary this would seem like trolling.

> So, yes, there are a ton of bad Java tools out there that provide a
> patch-work of functionality to service HTTP requests. The reason that there
> are so many is that the designs of these tools is by and large bad. Struts
> is an unmitigated piece of junk. JSF is not much better. And these are the
> leading contenders for front-end development.
>

From the original op on this thread he's not asking for front end
development just a server to recieve small requests.

I appreciate that you find Lift to be a well designed framework, I
can't disagree on that. I also appreciate you want to evangelise on
it, but the answer to all http related issues is not Lift.

I personally hate using html templating libraries and find jsf with
facelets an extremely productive environment to work in. I know I'm
in the minority for liking jsf but that doesn't imply that my choices
are worse. Lots of people seem to rate Wicket very highly.

Different frameworks appeal to different use cases, preferences and tastes.

> So, please help me with specifics so we can improve Lift.

If I ever have a need to use it I'm sure I will. Friends of mine have
had Lift as their first Scala experience and loved it, one raised a
problem on the list and had fixes by you within a day or so.

The results and flexibility of the framework and how much you want to
improve it are what will make people use it. Bringing it into
discussions without need won't.

Either way this has definitely left the realm of answering any of
Thomas's questions.

Hi David,

>> - Documentation
> Yep. It's a priority right now. All but 3 of the Lift committers are
> focused on documentation in preparation for the 1.0 release.

good to hear.

> You can put view code in your Scala, but you do not need to. You can
> bind all the dynamic pieces of your page content in such a way that no
> HTML lives in Scala code. It takes some discipline, but it is no more
> difficult than keeping HTML out of Java code.

I'm still not convinced. If you don't put it in Scala but in the view - can you
modify your view from Scala (e.g. change attributes)?

>> - Lift isn't really component-oriented
> CSS and HTML must be part of the WAR file or in some other way
> accessible to the web application. I don't know how one would drop of
> JAR file into a place in an app server outside the WAR file and have it
> accessible to the web app.

Sure it's part of the war - just within another jar in the lib-directory.

> Can you describe what you mean by components? Can you give examples of
> reuse across projects?

Think of a code block which shows an rss-feed. The only thing needed is to
provide a feed-url. The html and localization (properties) should just lie
within the jar containing this component.

All in all I find Wicket the better approach than Lift with Scala. It lets you
use the best of both functional and object oriented worlds with - IMHO - better
separation of concerns. Wicket's markup-inheritence with components plus Scala's
stacking of traits makes code duplication going down nearly to zero. Also,
Scala's concise code really makes development efficient (without having to
invest 4-6 months getting productive).

The only small annoyence is to have to include converters between Java and Scala
List/Iterators/Maps on a regular basis. But one get's used to that.

Regards, --- Jan.

On Mon, Jan 19, 2009 at 7:41 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

On 1/19/09, David Pollak <feeder.of.the.bears@gmail.com> wrote:
>
<snippage/>


> So, my question is partially requirements gathering.  You and Jan made
> statements that Lift does not satisfy the needs of this project.  I'd like
> to understand the specifics of why so we can improve Lift.
>

This is the exact point from my perspective.  I appreciate that Lift
is a powerful hammer but not every problem requires one.

Which is fine.  But, Tim's original statement was that Lift is the best tool to use for any non-trivial Servlet & Scala related stuff.  The operative statement is non-trivial.  You and Jan disagreed.  Jan has provided some reason for the disagreement which boils down to the fact that he's used to Wicket and more familiar with Wicket constructs than with Lift constructs. 
 

Axis, Muse, Xfire, birt and other tools handle different problem sets.
 Is your arguement really that instead of using tools more appropriate
for a given problem that we should use Lift or at least report why it
can't be used?

My argument is that Lift provides better support for non-trivial Servlet interfacing than any other mechanism is Scala.  I've demonstrated short code examples at both ends of the spectrum.  Jan has discussed why Wicket is better for him.  The discussion has come down to a matter of taste and experience with one or the other.
 

 

> So, yes, there are a ton of bad Java tools out there that provide a
> patch-work of functionality to service HTTP requests.  The reason that there
> are so many is that the designs of these tools is by and large bad.  Struts
> is an unmitigated piece of junk.  JSF is not much better.  And these are the
> leading contenders for front-end development.
>

From the original op on this thread he's not asking for front end
development just a server to recieve small requests.

Which Lift does with less code than any other framework that I'm aware of and Lift is very high performance.
 

I appreciate that you find Lift to be a well designed framework, I
can't disagree on that.  I also appreciate you want to evangelise on
it, but the answer to all http related issues is not Lift.

And I'm asking which ones.  Once again, outside of the package size issue, Lift provides a better solution from the most trivial to the most complex than any other system.  Like Scala, Lift is scalable.  And I will once again, put a caveat on the statement that Wicket and a few other frameworks will give people familiar with them marginally better developer performance than will Lift.
 

The results and flexibility of the framework and how much you want to
improve it are what will make people use it.  Bringing it into
discussions without need won't.

Tim made a suggestion.  You and Jan disagreed without providing any specifics.  My choices were to ignore the thread or to learn more about the disagreement and maybe demonstrate places where people had misperceptions about Lift.  I chose the latter.

Thanks,

David
 



--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On 1/19/09, David Pollak wrote:
>
>
> On Mon, Jan 19, 2009 at 7:41 AM, Chris Twiner
> wrote:
> >
> > On 1/19/09, David Pollak
> wrote:
> > >
> >
> >
> >
> >
> > > So, my question is partially requirements gathering. You and Jan made
> > > statements that Lift does not satisfy the needs of this project. I'd
> like
> > > to understand the specifics of why so we can improve Lift.
> > >
> >
> > This is the exact point from my perspective. I appreciate that Lift
> > is a powerful hammer but not every problem requires one.
>
> Which is fine. But, Tim's original statement was that Lift is the best tool
> to use for any non-trivial Servlet & Scala related stuff. The operative
> statement is non-trivial. You and Jan disagreed. Jan has provided some
> reason for the disagreement which boils down to the fact that he's used to
> Wicket and more familiar with Wicket constructs than with Lift constructs.

Sorry but this has gone way out of control. I would say exactly the
same regardless of what framework was mentioned as the "you should
use"..

> > I appreciate that you find Lift to be a well designed framework, I
> > can't disagree on that. I also appreciate you want to evangelise on
> > it, but the answer to all http related issues is not Lift.
>
> And I'm asking which ones.

I'm sorry this is way off-topic. How can you so flippantly assume
that Lift has all the answers to all the problems??? Hows your wsdl
support, or wsdm, ws-m, ws-sec? How does Lift handle osgi or jms
integration?

>Once again, outside of the package size issue,
> Lift provides a better solution from the most trivial to the most complex
> than any other system.

Its good you have such a high opinion of your software but this
statement is more than a little ridiculous. I'm fairly certain that
the authors of Struts thought the same.

> > The results and flexibility of the framework and how much you want to
> > improve it are what will make people use it. Bringing it into
> > discussions without need won't.
>
> Tim made a suggestion. You and Jan disagreed without providing any
> specifics.

The lack of specifics from Tims suggestion is the exact reason I
disagree with it. Again I restate that I would say the same of any
framework. Narrow down the requirements of any problem set and you
can then start to talk constructively about a given tool chain.

As the original poster I found the Lift discussion very interesting. But what I needed was a really simple way to get data from a third party site into may Swing Desktop application. The fact that I have an embedded HTTP server in my application opens several nice possibilities including ditching Swing for HTML/Javascript/AJAX.

To avoid a heated debate. I'll explain a little of what I'm doing. I created a simple application to help me run my table top RPG (role playing games for the non initiated). I choose Scala because it seemed to allow me to mix the nice things of functional programming (I had very good result with Lisp trial of this program) and the awesome array of Java libraries (which solves lisps poor UI capabilities). Turns out to be a good mix for me. Since I still want to keep the Table top aspect of the game this is a off-line stand-alone application. However, from the onset there are some possibilities that have taunted me: making it online. This would allow some sort of virtual table top control system.

If every player has a computer and can connect to the server, this would make up for a nice way to run remote games. I implemented my application as a set of actors that talk to each other. One core actor is the one that controles the state of all game elements. It send updates to observers (currently only one, the Swing UI), and receives actions from the user (via UI). I have considered implementing a distributed version of this were decisio.. I have considered implementing a distributed version of this were decision sent out to the player (when they have something to say) and then processed at the core actor. My original idea was to have several scala clients with remote agents. Which brings me to my Lift questions:

1) Can I have Browser handle like remote actors? Meaning they pool the server for messages and then update the view and ocassionally sent  out messages to be processed at the core?

2) Will Lift make it easier to implement such a behavior?

3) Could I intermingle Java Applets (say for a map view) and "Lift enabled AJAX/DHTML"?

Thanks, 

 Thomas

Whoah! I never meant to start such a debate - so, firstly, my apologies if I
offended anyone with my comment. The original statement was a touch vague,
yes, that's true, and as rightly discussed below, no framework could
possibly solve everyone's problems.

However, as this is a scala programming list, and the original poster was
obviously looking to create an application based on servlets and using
scala, I was merely suggesting that taking a look at lift might be a good
idea, as it is indeed a very nice web framework that happens to be written
in scala. At no point in time did I say "Lift is the uber framework that
tops all others", or anything along those lines.

So, Thomas, you can see from this thread that there are many different view
points here, and many many different ways to achieve whatever it is your
goals are - but before you choose your path, perhaps go checkout lift if you
feel so inclined. If its not for you, that's cool, if it is, then that's
cool too. Either way, good luck with your project.

Thanks, and sorry for stirring up the pot!

Cheers

Tim

On 19/01/2009 18:30, "Chris Twiner" wrote:

> On 1/19/09, David Pollak wrote:
>>
>>
>> On Mon, Jan 19, 2009 at 7:41 AM, Chris Twiner
>> wrote:
>>>
>>> On 1/19/09, David Pollak
>> wrote:
>>>>
>>>
>>>
>>>
>>>
>>>> So, my question is partially requirements gathering. You and Jan made
>>>> statements that Lift does not satisfy the needs of this project. I'd
>> like
>>>> to understand the specifics of why so we can improve Lift.
>>>>
>>>
>>> This is the exact point from my perspective. I appreciate that Lift
>>> is a powerful hammer but not every problem requires one.
>>
>> Which is fine. But, Tim's original statement was that Lift is the best tool
>> to use for any non-trivial Servlet & Scala related stuff. The operative
>> statement is non-trivial. You and Jan disagreed. Jan has provided some
>> reason for the disagreement which boils down to the fact that he's used to
>> Wicket and more familiar with Wicket constructs than with Lift constructs.
>
> Sorry but this has gone way out of control. I would say exactly the
> same regardless of what framework was mentioned as the "you should
> use"..
>
>>> I appreciate that you find Lift to be a well designed framework, I
>>> can't disagree on that. I also appreciate you want to evangelise on
>>> it, but the answer to all http related issues is not Lift.
>>
>> And I'm asking which ones.
>
> I'm sorry this is way off-topic. How can you so flippantly assume
> that Lift has all the answers to all the problems??? Hows your wsdl
> support, or wsdm, ws-m, ws-sec? How does Lift handle osgi or jms
> integration?
>
>> Once again, outside of the package size issue,
>> Lift provides a better solution from the most trivial to the most complex
>> than any other system.
>
> Its good you have such a high opinion of your software but this
> statement is more than a little ridiculous. I'm fairly certain that
> the authors of Struts thought the same.
>
>>> The results and flexibility of the framework and how much you want to
>>> improve it are what will make people use it. Bringing it into
>>> discussions without need won't.
>>
>> Tim made a suggestion. You and Jan disagreed without providing any
>> specifics.
>
> The lack of specifics from Tims suggestion is the exact reason I
> disagree with it. Again I restate that I would say the same of any
> framework. Narrow down the requirements of any problem set and you
> can then start to talk constructively about a given tool chain.
>

Chris,
Your arguments sound like those in Monty Python's Argument Clinic sketch.  You seem to think that you'll get your point across by continuously saying "you're wrong and I'm right."  You've given scant substantive arguments to support your assertion.  So, feel free not to use Lift.  But also, please don't keep saying "you're wrong and I'm right" without at least have the courtesy of making a substantive argument.
David

On Mon, Jan 19, 2009 at 10:30 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

On 1/19/09, David Pollak <feeder.of.the.bears@gmail.com> wrote:
>
>
> On Mon, Jan 19, 2009 at 7:41 AM, Chris Twiner <chris.twiner@gmail.com>
> wrote:
> >
> > On 1/19/09, David Pollak <feeder.of.the.bears@gmail.com>
> wrote:
> > >
> > <snippage/>
> >
> >
> >
> > > So, my question is partially requirements gathering.  You and Jan made
> > > statements that Lift does not satisfy the needs of this project.  I'd
> like
> > > to understand the specifics of why so we can improve Lift.
> > >
> >
> > This is the exact point from my perspective.  I appreciate that Lift
> > is a powerful hammer but not every problem requires one.
>
> Which is fine.  But, Tim's original statement was that Lift is the best tool
> to use for any non-trivial Servlet & Scala related stuff.  The operative
> statement is non-trivial.  You and Jan disagreed.  Jan has provided some
> reason for the disagreement which boils down to the fact that he's used to
> Wicket and more familiar with Wicket constructs than with Lift constructs.

Sorry but this has gone way out of control.  I would say exactly the
same regardless of what framework was mentioned as the "you should
use"..

> > I appreciate that you find Lift to be a well designed framework, I
> > can't disagree on that.  I also appreciate you want to evangelise on
> > it, but the answer to all http related issues is not Lift.
>
> And I'm asking which ones.

I'm sorry this is way off-topic.  How can you so flippantly assume
that Lift has all the answers to all the problems???  Hows your wsdl
support, or wsdm, ws-m, ws-sec?  How does Lift handle osgi or jms
integration?

>Once again, outside of the package size issue,
> Lift provides a better solution from the most trivial to the most complex
> than any other system.

Its good you have such a high opinion of your software but this
statement is more than a little ridiculous.  I'm fairly certain that
the authors of Struts thought the same.

> > The results and flexibility of the framework and how much you want to
> > improve it are what will make people use it.  Bringing it into
> > discussions without need won't.
>
> Tim made a suggestion.  You and Jan disagreed without providing any
> specifics.

The lack of specifics from Tims suggestion is the exact reason I
disagree with it.  Again I restate that I would say the same of any
framework.  Narrow down the requirements of any problem set and you
can then start to talk constructively about a given tool chain.

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Thomas,
I'd suggest discussion the substance of this over on the Lift list http://groups.google.com/group/liftweb

Just as a short answer... if you're running your application from a browser, the Java sandbox is very restrictive.  I'm sure you cannot listen at a TCP/IP port and I think you can only open an HTTP connection back to the original server.
If you are building a DHTML app (JavaScript and HTML) or a Flash app... there are many options for doing distributed game play using Lift and either of these client technologies.  http://buyafeature.com was implemented using Lift and is a multi-player game.  It uses the architecture that you've described behind the scenes (an Actor that manages state for the game connected to actors that proxy to the HTTP connections.)
I hope this over-view helps and I look forward to seeing you on the Lift list.
Thanks,
David
On Mon, Jan 19, 2009 at 10:47 AM, Thomas Sant Ana <mailleux@gmail.com> wrote:

As the original poster I found the Lift discussion very interesting. But what I needed was a really simple way to get data from a third party site into may Swing Desktop application. The fact that I have an embedded HTTP server in my application opens several nice possibilities including ditching Swing for HTML/Javascript/AJAX.

To avoid a heated debate. I'll explain a little of what I'm doing. I created a simple application to help me run my table top RPG (role playing games for the non initiated). I choose Scala because it seemed to allow me to mix the nice things of functional programming (I had very good result with Lisp trial of this program) and the awesome array of Java libraries (which solves lisps poor UI capabilities). Turns out to be a good mix for me. Since I still want to keep the Table top aspect of the game this is a off-line stand-alone application. However, from the onset there are some possibilities that have taunted me: making it online. This would allow some sort of virtual table top control system.

If every player has a computer and can connect to the server, this would make up for a nice way to run remote games. I implemented my application as a set of actors that talk to each other. One core actor is the one that controles the state of all game elements. It send updates to observers (currently only one, the Swing UI), and receives actions from the user (via UI). I have considered implementing a distributed version of this were decisio.. I have considered implementing a distributed version of this were decision sent out to the player (when they have something to say) and then processed at the core actor. My original idea was to have several scala clients with remote agents. Which brings me to my Lift questions:

1) Can I have Browser handle like remote actors? Meaning they pool the server for messages and then update the view and ocassionally sent  out messages to be processed at the core?

2) Will Lift make it easier to implement such a behavior?

3) Could I intermingle Java Applets (say for a map view) and "Lift enabled AJAX/DHTML"?

Thanks, 

 Thomas

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Obviously personal attacks carry far more weight then reason alone.
Never once did I attack Lift, but it seems to be have been taken as
such. Oh well, hopefully Lift can continue to thrive outside of such
commentary, but feel free to carry on attacking me like a dead parrot.

On 1/20/09, David Pollak wrote:
> Chris,
>
> Your arguments sound like those in Monty Python's Argument Clinic sketch.
> You seem to think that you'll get your point across by continuously saying
> "you're wrong and I'm right." You've given scant substantive arguments to
> support your assertion. So, feel free not to use Lift. But also, please
> don't keep saying "you're wrong and I'm right" without at least have the
> courtesy of making a substantive argument.
>
> David
>
>
> On Mon, Jan 19, 2009 at 10:30 AM, Chris Twiner
> wrote:
> >
> > On 1/19/09, David Pollak
> wrote:
> > >
> > >
> > > On Mon, Jan 19, 2009 at 7:41 AM, Chris Twiner
> > > wrote:
> > > >
> > > > On 1/19/09, David Pollak
>
> > > wrote:
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > > So, my question is partially requirements gathering. You and Jan
> made
> > > > > statements that Lift does not satisfy the needs of this project.
> I'd
> > > like
> > > > > to understand the specifics of why so we can improve Lift.
> > > > >
> > > >
> > > > This is the exact point from my perspective. I appreciate that Lift
> > > > is a powerful hammer but not every problem requires one.
> > >
> > > Which is fine. But, Tim's original statement was that Lift is the best
> tool
> > > to use for any non-trivial Servlet & Scala related stuff. The operative
> > > statement is non-trivial. You and Jan disagreed. Jan has provided some
> > > reason for the disagreement which boils down to the fact that he's used
> to
> > > Wicket and more familiar with Wicket constructs than with Lift
> constructs.
> >
> > Sorry but this has gone way out of control. I would say exactly the
> > same regardless of what framework was mentioned as the "you should
> > use"..
> >
> >
> > > > I appreciate that you find Lift to be a well designed framework, I
> > > > can't disagree on that. I also appreciate you want to evangelise on
> > > > it, but the answer to all http related issues is not Lift.
> > >
> > > And I'm asking which ones.
> >
> > I'm sorry this is way off-topic. How can you so flippantly assume
> > that Lift has all the answers to all the problems??? Hows your wsdl
> > support, or wsdm, ws-m, ws-sec? How does Lift handle osgi or jms
> > integration?
> >
> >
> > >Once again, outside of the package size issue,
> > > Lift provides a better solution from the most trivial to the most
> complex
> > > than any other system.
> >
> > Its good you have such a high opinion of your software but this
> > statement is more than a little ridiculous. I'm fairly certain that
> > the authors of Struts thought the same.
> >
> >
> > > > The results and flexibility of the framework and how much you want to
> > > > improve it are what will make people use it. Bringing it into
> > > > discussions without need won't.
> > >
> > > Tim made a suggestion. You and Jan disagreed without providing any
> > > specifics.
> >
> > The lack of specifics from Tims suggestion is the exact reason I
> > disagree with it. Again I restate that I would say the same of any
> > framework. Narrow down the requirements of any problem set and you
> > can then start to talk constructively about a given tool chain.
> >
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>

On Tue, Jan 20, 2009 at 9:04 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

Obviously personal attacks carry far more weight then reason alone.

Where have I attacked you personally?  I have stated that your assertions have no substance behind them and that you keep making the same assertions without any substantive argument.  Is this incorrect?
 

Never once did I attack Lift, but it seems to be have been taken as
such.

You have repeatedly asserted that Lift does not fulfill a broad spectrum of needs for writing HTTP-related applications.  You have not substantiated these claims, yet you continue to make them.  I am correcting (and will continue to correct) these assertions.
 

 Oh well, hopefully Lift can continue to thrive outside of such
commentary, but feel free to carry on attacking me like a dead parrot.

On 1/20/09, David Pollak <feeder.of.the.bears@gmail.com> wrote:
> Chris,
>
> Your arguments sound like those in Monty Python's Argument Clinic sketch.
> You seem to think that you'll get your point across by continuously saying
> "you're wrong and I'm right."  You've given scant substantive arguments to
> support your assertion.  So, feel free not to use Lift.  But also, please
> don't keep saying "you're wrong and I'm right" without at least have the
> courtesy of making a substantive argument.
>
> David
>
>
> On Mon, Jan 19, 2009 at 10:30 AM, Chris Twiner <chris.twiner@gmail.com>
> wrote:
> >
> > On 1/19/09, David Pollak <feeder.of.the.bears@gmail.com>
> wrote:
> > >
> > >
> > > On Mon, Jan 19, 2009 at 7:41 AM, Chris Twiner <chris.twiner@gmail.com>
> > > wrote:
> > > >
> > > > On 1/19/09, David Pollak
> <feeder.of.the.bears@gmail.com>
> > > wrote:
> > > > >
> > > > <snippage/>
> > > >
> > > >
> > > >
> > > > > So, my question is partially requirements gathering.  You and Jan
> made
> > > > > statements that Lift does not satisfy the needs of this project.
> I'd
> > > like
> > > > > to understand the specifics of why so we can improve Lift.
> > > > >
> > > >
> > > > This is the exact point from my perspective.  I appreciate that Lift
> > > > is a powerful hammer but not every problem requires one.
> > >
> > > Which is fine.  But, Tim's original statement was that Lift is the best
> tool
> > > to use for any non-trivial Servlet & Scala related stuff.  The operative
> > > statement is non-trivial.  You and Jan disagreed.  Jan has provided some
> > > reason for the disagreement which boils down to the fact that he's used
> to
> > > Wicket and more familiar with Wicket constructs than with Lift
> constructs.
> >
> > Sorry but this has gone way out of control.  I would say exactly the
> > same regardless of what framework was mentioned as the "you should
> > use"..
> >
> >
> > > > I appreciate that you find Lift to be a well designed framework, I
> > > > can't disagree on that.  I also appreciate you want to evangelise on
> > > > it, but the answer to all http related issues is not Lift.
> > >
> > > And I'm asking which ones.
> >
> > I'm sorry this is way off-topic.  How can you so flippantly assume
> > that Lift has all the answers to all the problems???  Hows your wsdl
> > support, or wsdm, ws-m, ws-sec?  How does Lift handle osgi or jms
> > integration?
> >
> >
> > >Once again, outside of the package size issue,
> > > Lift provides a better solution from the most trivial to the most
> complex
> > > than any other system.
> >
> > Its good you have such a high opinion of your software but this
> > statement is more than a little ridiculous.  I'm fairly certain that
> > the authors of Struts thought the same.
> >
> >
> > > > The results and flexibility of the framework and how much you want to
> > > > improve it are what will make people use it.  Bringing it into
> > > > discussions without need won't.
> > >
> > > Tim made a suggestion.  You and Jan disagreed without providing any
> > > specifics.
> >
> > The lack of specifics from Tims suggestion is the exact reason I
> > disagree with it.  Again I restate that I would say the same of any
> > framework.  Narrow down the requirements of any problem set and you
> > can then start to talk constructively about a given tool chain.
> >
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
>  Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For what it might be worth to anyone out there, we made the
unfortunate decision of using Lift in a production application against
my warnings and we are now paying the price heavily in many ways (too
many to enumerate). "I told you so" is a poor consolation prize, but I
suppose lessons are there to be learned.

- --
Tony Morris
http://tmorris.net/

S, K and I ought to be enough for anybody.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJdk/VmnpgrYe6r60RAjAiAJ9QdAX4W2kKY4f25tY69EmN0fkDkQCgySef
hHaNoW4LZsqyqbAW9NRB5oI=
=If6q
-----END PGP SIGNATURE-----

On Tue, Jan 20, 2009 at 11:27 PM, Tony Morris <tmorris@tmorris.net> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For what it might be worth to anyone out there, we made the
unfortunate decision of using Lift in a production application against
my warnings and we are now paying the price heavily in many ways (too
many to enumerate). "I told you so" is a poor consolation prize, but I
suppose lessons are there to be learned.

Tony, we've had our differences over the past year-and-a-half, and as a lift-team member, I might not look like the average "objective" person out there.

But this statement you've made above is exactly what you cracked down on Catchpole on the Javaposse list for doing.

So help lift get better by giving feedback, or just refrain from non-substantial claims of crappiness.

That's just my 2 cents,

Cheers,
Viktor

 

- --
Tony Morris
http://tmorris.net/

S, K and I ought to be enough for anybody.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJdk/VmnpgrYe6r60RAjAiAJ9QdAX4W2kKY4f25tY69EmN0fkDkQCgySef
hHaNoW4LZsqyqbAW9NRB5oI=
=If6q
-----END PGP SIGNATURE-----

--
Viktor Klang
Senior Systems Analyst

Thomas Sant Ana schrieb:
> I want to know if there is a small Java HTTP Server that allows me to
> get POST request and maybe some GET and pass them on to some Scala code.

Another possibility might be grizzly.
If you have a directory like this:

-rw-r--r-- 1 hars hars 697840 2009-02-01 16:23 grizzly-module.jar
-rw-r--r-- 1 hars hars 95 2009-02-01 16:24 hello.html

you can just start scala there with

$ scala -cp grizzly-module.jar

and paste this script into the interpreter:

import com.sun.grizzly.tcp.http11._
import com.sun.grizzly.http.embed._
val ws = new GrizzlyWebServer(8880)
val ad = new GrizzlyAdapter(".") {
def service(rq: GrizzlyRequest, resp: GrizzlyResponse) {
val r = {rq.getMethod()}: {rq.getDecodedRequestURI()}
resp.getWriter().println(r.toString)
}
}
ad.setHandleStaticResources(true)
ws.addGrizzlyAdapter(ad)
ws.start()
val xp = new scala.xml.parsing.NoBindingFactoryAdapter
xp load "http://localhost:8880/bar"
xp load "http://localhost:8880/hello.html"

The results will be:
res3: scala.xml.Node = GET: /bar
and
res4: scala.xml.Node =

Hello, grizzly

Hello, grizzly

While the interpreter is still running, you can try this in another
shell:

$ LANG=C wget --quiet --post-data=X=Y -O - http://localhost:8880/qux
POST: /qux

Another option is to use a ServletAdapter and write your code as a
standard servlet.

- Florian.