Re: [ANN] Async Ring 0.1.0

2014-09-10 Thread dgrnbrg 
Hi Paul,
Thanks for your feedback! I updated the comparison with pedestal when 
discussing the async queues to address this point.

I am also really excited about Jet--I think that it would be a great 
combination with Spiral!

One key difference in Spiral from Jet and Pedestal is that not only can you 
use core.async to make an async handler, but you can also make async 
middleware using core.async as well.

On Wednesday, September 10, 2014 6:29:11 AM UTC-4, Paul deGrandis wrote:
>
> Hi David,
>
> It's excellent to see this tools and others like it (eg: Max Penet's Jet - 
> https://github.com/mpenet/jet)!  The more ideas we get in this area, the 
> better all the tooling will become.
> There are a few things I'd like to clear about the notion of asynchronous 
> processing in general and the comparison to Pedestal specifically.  I think 
> in discussing the details, everyone will come out ahead.
>
> 1. The interceptor queue is merely the current path.
> In your comparison, you state that Pedestal forces Interceptors to be 
> placed in a queue for execution.  This isn't entirely accurate.  You can 
> arbitrarily specify the order of interceptors (imagine a graph of connected 
> interceptors).  The interceptor queue is merely the current path of 
> interceptors executing (or scheduled to execute).  Any interceptor can 
> dynamically add more interceptors to that path during execution.  The 
> "interceptor" is the core abstraction from which all things are built in 
> Pedestal - it's the only abstraction.
> I have written a predicate dispatch Interceptor that allows 
> open/extensible rules to route requests - with the interceptor you can 
> create a Liberator-style system, QoS-style routing, or anything of similar 
> nature.  I also have written a cond-interceptor, that does a one-off 
> conditional dispatch.  Both will probably land in Pedestal's base 
> interceptors at some point.
>
> 2. One notion of concurrency in Pedestal is managed with core.async
> In your comparison, you state the concurrency mechanism is pure 
> functions.  This is also not accurate.  The concurrency mechanism to signal 
> to the container you're going async, is to have an interceptor return a 
> core.async channel (we'll call this the "context channel").  In the 
> application code, you continue forward using core.async.  Once you want the 
> web-server to resume processing your request, you place a context (a map) 
> on the context channel (sometimes others refer to the context channel as 
> the "resume channel").  I think what you're getting at is there's a notion 
> of interceptors for entering, leaving, and handling errors - which I'll 
> address in the next item.
>
> 3. There are two notions of async behavior - Pedestal delivers both.
> One notion of async behavior was discussed above - your application gives 
> up the current/main execution thread, continues execution on another 
> thread, and later gets resumed on one of the main execution threads.  To 
> truly do this in an asynchronous manner, one must separate the notion of 
> request and response.  This is why Pedestal uses a context, and why 
> function composition and coupling request and response will limit (or 
> prevent) async capabilities.  To be async in this sense, you must never 
> block the main execution thread at any point.
> Another notion of async behavior occurs when placing the actual response 
> on the wire - most applications do so in a blocking manner using standard 
> Java IO.  Recently, Pedestal added the capability to do this in a 
> non-blocking, asynchronous manner using NIO.  That is, in Pedestal, if your 
> response body is a ByteBuffer or a ReadableByteChannel, and you're running 
> on a container that supports NIO (Jetty), it will use NIO through the 
> entire container when handling the request.  If a developer can't get 
> manage to return a ByteBuffer or a ReadableByteChannel (or if the developer 
> is on a container that doesn't support NIO), they can still return a 
> core.async Channel and Pedestal will perform the standard IO response 
> within a `go`.  Using a core.async Channel has limits, and NIO should be 
> preferred if available.
>
> 4. Routing and Extension
> Two pieces missing from the comparison were routing and general extension 
> mechanisms.  I won't dive too deep into the routing piece (it's data 
> driven, can be programmatically consumed or generated, can be read off of 
> the wire or out of a DB, etc), but I do want to touch upon the extension 
> piece a bit.  In Pedestal, all the major integration points are backed by 
> protocols - including the async handling discussed above.  This allows 
> developers to shape and extend Pedestal to fit any operational need.  
> Routing is also backed by protocols, which enables a developer to shape how 
> routing endpoints should be interrupted.  Pedestal's use of protocols
> throughout has proven extremely beneficial as I've tackled complex web 
> systems.
>
> I hope this helps cla

Re: [ANN] Async Ring 0.1.0

2014-09-10 Thread Paul deGrandis 
Hi David,

It's excellent to see this tools and others like it (eg: Max Penet's Jet - 
https://github.com/mpenet/jet)!  The more ideas we get in this area, the 
better all the tooling will become.
There are a few things I'd like to clear about the notion of asynchronous 
processing in general and the comparison to Pedestal specifically.  I think 
in discussing the details, everyone will come out ahead.

1. The interceptor queue is merely the current path.
In your comparison, you state that Pedestal forces Interceptors to be 
placed in a queue for execution.  This isn't entirely accurate.  You can 
arbitrarily specify the order of interceptors (imagine a graph of connected 
interceptors).  The interceptor queue is merely the current path of 
interceptors executing (or scheduled to execute).  Any interceptor can 
dynamically add more interceptors to that path during execution.  The 
"interceptor" is the core abstraction from which all things are built in 
Pedestal - it's the only abstraction.
I have written a predicate dispatch Interceptor that allows open/extensible 
rules to route requests - with the interceptor you can create a 
Liberator-style system, QoS-style routing, or anything of similar nature.  
I also have written a cond-interceptor, that does a one-off conditional 
dispatch.  Both will probably land in Pedestal's base interceptors at some 
point.

2. One notion of concurrency in Pedestal is managed with core.async
In your comparison, you state the concurrency mechanism is pure functions.  
This is also not accurate.  The concurrency mechanism to signal to the 
container you're going async, is to have an interceptor return a core.async 
channel (we'll call this the "context channel").  In the application code, 
you continue forward using core.async.  Once you want the web-server to 
resume processing your request, you place a context (a map) on the context 
channel (sometimes others refer to the context channel as the "resume 
channel").  I think what you're getting at is there's a notion of 
interceptors for entering, leaving, and handling errors - which I'll 
address in the next item.

3. There are two notions of async behavior - Pedestal delivers both.
One notion of async behavior was discussed above - your application gives 
up the current/main execution thread, continues execution on another 
thread, and later gets resumed on one of the main execution threads.  To 
truly do this in an asynchronous manner, one must separate the notion of 
request and response.  This is why Pedestal uses a context, and why 
function composition and coupling request and response will limit (or 
prevent) async capabilities.  To be async in this sense, you must never 
block the main execution thread at any point.
Another notion of async behavior occurs when placing the actual response on 
the wire - most applications do so in a blocking manner using standard Java 
IO.  Recently, Pedestal added the capability to do this in a non-blocking, 
asynchronous manner using NIO.  That is, in Pedestal, if your response body 
is a ByteBuffer or a ReadableByteChannel, and you're running on a container 
that supports NIO (Jetty), it will use NIO through the entire container 
when handling the request.  If a developer can't get manage to return a 
ByteBuffer or a ReadableByteChannel (or if the developer is on a container 
that doesn't support NIO), they can still return a core.async Channel and 
Pedestal will perform the standard IO response within a `go`.  Using a 
core.async Channel has limits, and NIO should be preferred if available.

4. Routing and Extension
Two pieces missing from the comparison were routing and general extension 
mechanisms.  I won't dive too deep into the routing piece (it's data 
driven, can be programmatically consumed or generated, can be read off of 
the wire or out of a DB, etc), but I do want to touch upon the extension 
piece a bit.  In Pedestal, all the major integration points are backed by 
protocols - including the async handling discussed above.  This allows 
developers to shape and extend Pedestal to fit any operational need.  
Routing is also backed by protocols, which enables a developer to shape how 
routing endpoints should be interrupted.  Pedestal's use of protocols
throughout has proven extremely beneficial as I've tackled complex web 
systems.

I hope this helps clarify some topics and I look forward to further 
discussion!

Cheers,
Paul

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop rece

Re: [ANN] Async Ring 0.1.0

2014-09-09 Thread bob 
Great, I just wonder how you evaluate the performance, how many 
concurrences? how many requests?

On Tuesday, September 9, 2014 11:25:04 PM UTC+8, dgrnbrg wrote:
>
> Announcing the release of Async Ring! Ring is a great foundation for 
> building HTTP servers in Clojure. However, Ring fails to solve many 
> problems that high-performance and transactional HTTP servers must solve:
>
>
>- What does the server do when it can't handle the request rate?
>- How can the server dedicate more or fewer resources to different 
>requests?
>- How can long-running HTTP requests be easily developed, without 
>blocking threads?
>
>
> Async Ring attempts to solve these problems by introducing a core.async 
> based API that is backwards compatible with Ring and popular Ring servers, 
> so that you don't need to rewrite your app to take advantage of these 
> techniques.
>
>
> Async Ring comes with many features:
>
>- Ports of most ring middleware (just ask me and I'll port your 
>favorites!)
>- Beauty, a compojure & clout compatible concurrent quality-of-server 
>router
>- Integration with Jetty and Http-Kit, more coming
>- Documentation and Examples
>
>
> Take a look here: https://github.com/dgrnbrg/async-ring
>
> Feedback and pull requests welcome!
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Async Ring 0.1.0

2014-09-09 Thread dgrnbrg 
Async Ring has been renamed to Spiral, a Ring that doesn't block, to avoid 
future confusion.

On Tuesday, September 9, 2014 12:50:11 PM UTC-4, James Reeves wrote:
>
> Hi David,
>
> This looks very interesting, however I'd like to request that you change 
> the name to make it clear this project isn't an official part of Ring. 
> Usually I don't mind if a library uses "Ring" in its name, but in this case 
> it seems like there could be a future source of confusion if Ring itself 
> adopts an asynchronous approach.
>
> - James
>
>
> On 9 September 2014 16:24, David Greenberg  > wrote:
>
>> Announcing the release of Async Ring! Ring is a great foundation for 
>> building HTTP servers in Clojure. However, Ring fails to solve many 
>> problems that high-performance and transactional HTTP servers must solve:
>>
>>
>>- What does the server do when it can't handle the request rate?
>>- How can the server dedicate more or fewer resources to different 
>>requests?
>>- How can long-running HTTP requests be easily developed, without 
>>blocking threads?
>>
>>
>> Async Ring attempts to solve these problems by introducing a core.async 
>> based API that is backwards compatible with Ring and popular Ring servers, 
>> so that you don't need to rewrite your app to take advantage of these 
>> techniques.
>>
>>
>> Async Ring comes with many features:
>>
>>- Ports of most ring middleware (just ask me and I'll port your 
>>favorites!)
>>- Beauty, a compojure & clout compatible concurrent quality-of-server 
>>router
>>- Integration with Jetty and Http-Kit, more coming
>>- Documentation and Examples
>>
>>
>> Take a look here: https://github.com/dgrnbrg/async-ring
>>
>> Feedback and pull requests welcome!
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Async Ring 0.1.0

2014-09-09 Thread David Greenberg 
Async Ring has been renamed to Spiral, a Ring that doesn't block, to avoid 
future confusion.

On Tuesday, September 9, 2014 12:50:00 PM UTC-4, James Reeves wrote:
>
> Hi David,
>
> This looks very interesting, however I'd like to request that you change 
> the name to make it clear this project isn't an official part of Ring. 
> Usually I don't mind if a library uses "Ring" in its name, but in this case 
> it seems like there could be a future source of confusion if Ring itself 
> adopts an asynchronous approach.
>
> - James
>
>
> On 9 September 2014 16:24, David Greenberg  > wrote:
>
>> Announcing the release of Async Ring! Ring is a great foundation for 
>> building HTTP servers in Clojure. However, Ring fails to solve many 
>> problems that high-performance and transactional HTTP servers must solve:
>>
>>
>>- What does the server do when it can't handle the request rate?
>>- How can the server dedicate more or fewer resources to different 
>>requests?
>>- How can long-running HTTP requests be easily developed, without 
>>blocking threads?
>>
>>
>> Async Ring attempts to solve these problems by introducing a core.async 
>> based API that is backwards compatible with Ring and popular Ring servers, 
>> so that you don't need to rewrite your app to take advantage of these 
>> techniques.
>>
>>
>> Async Ring comes with many features:
>>
>>- Ports of most ring middleware (just ask me and I'll port your 
>>favorites!)
>>- Beauty, a compojure & clout compatible concurrent quality-of-server 
>>router
>>- Integration with Jetty and Http-Kit, more coming
>>- Documentation and Examples
>>
>>
>> Take a look here: https://github.com/dgrnbrg/async-ring
>>
>> Feedback and pull requests welcome!
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Async Ring 0.1.0

2014-09-09 Thread James Reeves 
Hi David,

This looks very interesting, however I'd like to request that you change
the name to make it clear this project isn't an official part of Ring.
Usually I don't mind if a library uses "Ring" in its name, but in this case
it seems like there could be a future source of confusion if Ring itself
adopts an asynchronous approach.

- James


On 9 September 2014 16:24, David Greenberg  wrote:

> Announcing the release of Async Ring! Ring is a great foundation for
> building HTTP servers in Clojure. However, Ring fails to solve many
> problems that high-performance and transactional HTTP servers must solve:
>
>
>- What does the server do when it can't handle the request rate?
>- How can the server dedicate more or fewer resources to different
>requests?
>- How can long-running HTTP requests be easily developed, without
>blocking threads?
>
>
> Async Ring attempts to solve these problems by introducing a core.async
> based API that is backwards compatible with Ring and popular Ring servers,
> so that you don't need to rewrite your app to take advantage of these
> techniques.
>
>
> Async Ring comes with many features:
>
>- Ports of most ring middleware (just ask me and I'll port your
>favorites!)
>- Beauty, a compojure & clout compatible concurrent quality-of-server
>router
>- Integration with Jetty and Http-Kit, more coming
>- Documentation and Examples
>
>
> Take a look here: https://github.com/dgrnbrg/async-ring
>
> Feedback and pull requests welcome!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Async Ring 0.1.0

2014-09-09 Thread László Török 
There seems to be a
https://github.com/dgrnbrg/async-ring#comparison-with-pedestal section in
the README

2014-09-09 16:34 GMT+01:00 Timothy Baldridge :

> How does this compare/contrast with Pedestal. Seems like there might be
> some overlap here?
>
> Timothy
>
> On Tue, Sep 9, 2014 at 9:24 AM, David Greenberg 
> wrote:
>
>> Announcing the release of Async Ring! Ring is a great foundation for
>> building HTTP servers in Clojure. However, Ring fails to solve many
>> problems that high-performance and transactional HTTP servers must solve:
>>
>>
>>- What does the server do when it can't handle the request rate?
>>- How can the server dedicate more or fewer resources to different
>>requests?
>>- How can long-running HTTP requests be easily developed, without
>>blocking threads?
>>
>>
>> Async Ring attempts to solve these problems by introducing a core.async
>> based API that is backwards compatible with Ring and popular Ring servers,
>> so that you don't need to rewrite your app to take advantage of these
>> techniques.
>>
>>
>> Async Ring comes with many features:
>>
>>- Ports of most ring middleware (just ask me and I'll port your
>>favorites!)
>>- Beauty, a compojure & clout compatible concurrent quality-of-server
>>router
>>- Integration with Jetty and Http-Kit, more coming
>>- Documentation and Examples
>>
>>
>> Take a look here: https://github.com/dgrnbrg/async-ring
>>
>> Feedback and pull requests welcome!
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
László Török
Checkout Lollyrewards.com  - Giving credit,
getting credit.
Follow us on Twitter @lollyrewards 
Stay up to date on the latest offers by liking our Facebook page
.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Async Ring 0.1.0

2014-09-09 Thread Timothy Baldridge 
How does this compare/contrast with Pedestal. Seems like there might be
some overlap here?

Timothy

On Tue, Sep 9, 2014 at 9:24 AM, David Greenberg 
wrote:

> Announcing the release of Async Ring! Ring is a great foundation for
> building HTTP servers in Clojure. However, Ring fails to solve many
> problems that high-performance and transactional HTTP servers must solve:
>
>
>- What does the server do when it can't handle the request rate?
>- How can the server dedicate more or fewer resources to different
>requests?
>- How can long-running HTTP requests be easily developed, without
>blocking threads?
>
>
> Async Ring attempts to solve these problems by introducing a core.async
> based API that is backwards compatible with Ring and popular Ring servers,
> so that you don't need to rewrite your app to take advantage of these
> techniques.
>
>
> Async Ring comes with many features:
>
>- Ports of most ring middleware (just ask me and I'll port your
>favorites!)
>- Beauty, a compojure & clout compatible concurrent quality-of-server
>router
>- Integration with Jetty and Http-Kit, more coming
>- Documentation and Examples
>
>
> Take a look here: https://github.com/dgrnbrg/async-ring
>
> Feedback and pull requests welcome!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Async Ring 0.1.0

2014-09-09 Thread David Greenberg 
Announcing the release of Async Ring! Ring is a great foundation for
building HTTP servers in Clojure. However, Ring fails to solve many
problems that high-performance and transactional HTTP servers must solve:


   - What does the server do when it can't handle the request rate?
   - How can the server dedicate more or fewer resources to different
   requests?
   - How can long-running HTTP requests be easily developed, without
   blocking threads?


Async Ring attempts to solve these problems by introducing a core.async
based API that is backwards compatible with Ring and popular Ring servers,
so that you don't need to rewrite your app to take advantage of these
techniques.


Async Ring comes with many features:

   - Ports of most ring middleware (just ask me and I'll port your
   favorites!)
   - Beauty, a compojure & clout compatible concurrent quality-of-server
   router
   - Integration with Jetty and Http-Kit, more coming
   - Documentation and Examples


Take a look here: https://github.com/dgrnbrg/async-ring

Feedback and pull requests welcome!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.