Snack (WSGI/Rack for Scala)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Snack (WSGI/Rack for Scala)

pk11
This post was updated on .
Hi all,

As I mentioned to both Nathan and Doug in person and also on twitter, I am working on a project which tries to unify most of the scala micro webframeworks (pinky, scalactra, unfiltered) in such a way that they they would implement a common API - that way components (templating, backends, async http, akka, app creation, testing,  authentication, microformat support etc) written for any of those frameworks could be shared across the board. Similar ideas exist in python[WSGI] and ruby[Rack] (in fact, rack was heavily inspired by WSGI). Consequently, the scala API could be called Snack (working title).


I found Unfiltered HttpRequest/HttpResponse a very good starting point.

My current plan is the following:

- create a generic Snack Plan in unfiltered which would be backend independent, this plan would be used by Snack compatible client code.

- backends (currently jetty, netty) could be configured alongside Snack Plans in the Snack webapp's main method (wiring could be part of Snack's API too)

- add async http placeholder method to Snack Plan and implement it for both netty and jetty backend (the latter could have two versions, one is using jetty
continuation, the other one could use servlet 3.0 async http)

- migrate pinky's and scalatra's DSL over the new generic plan

- migrate pinky components over the new generic plan

If anyone wants to participate in the API design and/or in the implementation, please let me know!  (both Nathan and Doug were kind enough to offer their help)

Thoughts?

Cheers,
Peter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snack (WSGI/Rack for Scala)

soft_props


On Sun, Jul 24, 2011 at 6:17 PM, pk11 [via Databinder] <[hidden email]> wrote:
Hi all,

As I mentioned to both Nathan and Doug in person and also on twitter, I am working on a project which tries to unify most of the scala micro webframeworks (pinky, scalactra, unfiltered) in such a way that they they would implement a common API - that way components (templating, backends, async http, akka, app creation, testing,  authentication, microformat support etc) written for any of those frameworks could be shared across the board. Similar ideas exist in python[WSGI] and ruby[Rack] (in fact, rack was heavily inspired by WSGI). Consequently, the scala API could be called Snack (working title).



mmm. Let's work on that. It is common for other like language impls to follow suit namewise with rack, plack (perl), and jack (js), but I don't know if snack has the same ring for scala. I don't think that the rack/wsgi module is very well suited for scala in general but if we can come up with something more inline with scala (typesafe), that would be cool. Let's work on that name :)


I found Unfiltered HttpRequest/HttpResponse a very good starting point.

My current plan is the following:

- create a generic Snack Plan in unfiltered which would be backend independent, this plan would be used by Snack compatible client code.


Nathan already did a lot of work here decoupling intents [1] from backends.
 
- backends (currently jetty, netty) could be configured alongside Snack Plans in the Snack webapp's main method (wiring could be part of Snack's API too)


There are some starting point examples of backend bindings for servlet envs [2] and netty envs [3]. These are pretty straight forward for someone to write for new backends like grizzly [4] for instance.

 
- add async http placeholder method to Snack Plan and implement it for both netty and jetty backend (the latter could have two versions, one is using jetty
continuation, the other one could use servlet 3.0 async http)


I'd like to hear more about jetty continuations. The netty backends don't have to be tied any version of the the servlet api. It's not right now. A new module that would help support a more async servlet api would be attractive though.

 
- migrate pinky's and scalatra's DSL over the new generic plan

- migrate pinky components over the new generic plan


I don't have a whole lot of expertise on these :)

 
If anyone wants to participate in the API design and/or in the implementation, please let me know!  (both Nathan and Doug were kind of enough to offer their help)


If there are enough people in the nyc area it would be cool to get together in person to talk about this some time. Sometimes a white board is better than back and forth conversation over email. The philsophy so far is to have just the right about of abstraction and still enable users to access the underlying impls. Too much abstraction may actually add complexity which I'd like to avoid.


max
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snack (WSGI/Rack for Scala)

max
On Sun, Jul 24, 2011 at 18:46, soft_props [via Databinder]
<[hidden email]> wrote:
> If there are enough people in the nyc area it would be cool to get together
> in person to talk about this some time. Sometimes a white board is better
> than back and forth conversation over email.

Wait for Chris Lewis to come to NYC, then we can all get together at
Novus & discuss this.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snack (WSGI/Rack for Scala)

soft_props

Wait for Chris Lewis to come to NYC, then we can all get together at
Novus & discuss this.


Definitely!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snack (WSGI/Rack for Scala)

pk11
Max, When is Chris coming?

soft_props wrote
mmm. Let's work on that. It is common for other like language impls to follow suit namewise with rack, plack (perl), and jack (js), but I don't know if snack has the same ring for scala. I don't think that the rack/wsgi module is very well suited for scala in general but if we can come up with something more inline with scala (typesafe), that would be cool. Let's work on that name :)

Doug, I do not mind the name either way, just wanted to have at least a working title:)
As for whether it's going to be useful, I suppose it mainly depends on whether we can come up with a good API that all of us would adapt (not sure if it was clear from my previous email but from the 3 frameworks unfiltered would be largely unaffected). Also,  I agree with your point about type safety. I believe the only area where implementations would mainly differ is how the URI -> request/response mapping is done but that would be an API implementation detail not the API itself.

soft_props wrote
Nathan already did a lot of work here decoupling intents [1] from backends.
I am aware of Cycle, what I was thinking about is an abstract Plan based on Cycle (not sure if that makes sense).


 
soft_props wrote
If there are enough people in the nyc area it would be cool to get together in person to talk about this some time. Sometimes a white board is better than back and forth conversation over email. The philsophy so far is to have just the right about of abstraction and still enable users to access the underlying impls. Too much abstraction may actually add complexity which I'd like to avoid.
Sounds good let's get together!

 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snack (WSGI/Rack for Scala)

chris_lewis
Hi Peter,

August 8th, 2 weeks from tomorrow is my first day at Novus. I should be fairly set up that weekend, and I plan on being at found weekends Saturday July 30th - I hope that's not too long.

I'm definitely interested in this idea, even if I'm not sure how it might look. I'll check out scalatra and pinky - I haven't dug into any of the micro frameworks since Unfiltered surfaced - it just fit. I'm quite familiar with its internals, but I'll do some catch up on the others. That said, I'd like to understand better what you want to accomplish. The idea of some unified interface would be good, and if you're talking about Plans, that's an easy target. Apart from the Plan and backend abstraction, which Nathan has done a dang good job on, I'm not sure what's left. Incidentally, to me that is one of the nicest parts of Unfiltered: what it *doesn't* do.

Anyway, I'd like to get a clearer picture and would definitely be in on a project that can make things easier to put out correct, lean code.

-chris
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snack (WSGI/Rack for Scala)

pk11
Hi Chris,

Early August sounds good!

> Apart from the Plan and backend abstraction, which Nathan has done a dang good job on, I'm not sure what's left.

That's what I meant by unfiltered would be largely unaffected. Aside from the abstract plan, I could see only two other changes (none of them would be breaking):
- unifying server startup API
(as far as I remember right now it looks something like this:
netty: unfiltered.netty.Http(8080).handler(new NettyPlan1).handler(new NettyPlan2).run
jetty: unfiltered.jetty.Http(8080).filter(new MyFilterPlan1).filter(new MyFilterPlan2).run)
- adding an async http handler to abstract plan and implement it for both backends


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snack (WSGI/Rack for Scala)

chris_lewis
On 7/24/11 9:37 PM, pk11 [via Databinder] wrote:
Hi Chris,

Early August sounds good!
Great!

> Apart from the Plan and backend abstraction, which Nathan has done a dang good job on, I'm not sure what's left.

That's what I meant by unfiltered would be largely unaffected. Aside from the abstract plan, I could see only two other changes (none of them would be breaking):
- unifying server startup API
(as far as I remember right now it looks something like this:
netty: unfiltered.netty.Http(8080).handler(new NettyPlan1).handler(new NettyPlan2).run
jetty: unfiltered.jetty.Http(8080).filter(new MyFilterPlan1).filter(new MyFilterPlan2).run)
- adding an async http handler to abstract plan and implement it for both backends
Ah, ok. Certainly seems doable, but we'll want to keep the underlying backend available when lower-level tweaking is needed. A common lowest-common-denominator abstraction with an "underlying" available, just like Plans, should do.





If you reply to this email, your message will be added to the discussion below:
http://databinder.3617998.n2.nabble.com/Snack-WSGI-Rack-for-Scala-tp6616557p6616874.html
To start a new topic under Unfiltered, email [hidden email]
To unsubscribe from Unfiltered, click here.

Loading...