node.groovy?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
12
Reply | Threaded
Open this post in threaded view
|

node.groovy?

Jon Brisbin
I've been spending some time in node.js lately and I love the asynchronous nature of it. I also have resigned myself to the fact of using Javascript (again).

But it would be awesome to have "node.groovy", a lightweight async framework where Groovy fans could share the lightweight love that Sinatra and Node.js folks get. I'm kinda jealous.

Anyone thought of implementing an async I/O framework like Node.js in Groovy? How hard could it be if not? Pros? Cons? Thoughts?

Thanks!

Jon Brisbin

        Web: http://jbrisbin.com/
    Twitter: @j_brisbin
      Skype: jon.brisbin

Reply | Threaded
Open this post in threaded view
|

Re: node.groovy?

Jochen Theodorou
Jon Brisbin wrote:

> I've been spending some time in node.js lately and I love the
> asynchronous nature of it. I also have resigned myself to the fact of
> using Javascript (again).
>
> But it would be awesome to have "node.groovy", a lightweight async
> framework where Groovy fans could share the lightweight love that
> Sinatra and Node.js folks get. I'm kinda jealous.
>
> Anyone thought of implementing an async I/O framework like Node.js in
> Groovy? How hard could it be if not? Pros? Cons? Thoughts?

but for node.js the typical usage should be from within the browser...
and then I expect it not doing more than http based communication with a
webserver in the end.

What exactly is it you would want for Groovy there?

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: node.groovy?

Alex Tkachman
In reply to this post by Jon Brisbin
Have a look on https://github.com/alextkachman/gretty It is movement
in that direction

On Fri, Dec 17, 2010 at 4:33 PM, Jon Brisbin <[hidden email]> wrote:

> I've been spending some time in node.js lately and I love the asynchronous
> nature of it. I also have resigned myself to the fact of using Javascript
> (again).
> But it would be awesome to have "node.groovy", a lightweight async framework
> where Groovy fans could share the lightweight love that Sinatra and Node.js
> folks get. I'm kinda jealous.
> Anyone thought of implementing an async I/O framework like Node.js in
> Groovy? How hard could it be if not? Pros? Cons? Thoughts?
>
> Thanks!
> Jon Brisbin
>         Web: http://jbrisbin.com/
>     Twitter: @j_brisbin
>       Skype: jon.brisbin
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: node.groovy?

Jon Brisbin
In reply to this post by Jochen Theodorou

On Dec 17, 2010, at 10:56 AM, Jochen Theodorou wrote:

but for node.js the typical usage should be from within the browser... and then I expect it not doing more than http based communication with a webserver in the end.

Certainly people use node.js for webapps heavily, but Node.js itself is a general-purpose async I/O framework. It's great for integrating messaging and whatnot as well.

What exactly is it you would want for Groovy there?

I love the Groovy language and would love to have a really lightweight, asynchronous (Closure-based) framework for developing web and other applications that could make use of all the DSLs and Java libs I'm used to without the blocking semantics of thread-based app servers.

Instead of implementing interfaces and all that, it would be great to simply pass closures. I already do something similar to this in my custom Groovy-based web framework. The difference with my framework is that it runs from a Spring MVC controller and can't make use of the higher throughput obtainable using async request processing.

Quite a bit of work? Likely. But worth it, IMHO.

Thanks!

Jon Brisbin

        Web: http://jbrisbin.com/
    Twitter: @j_brisbin
      Skype: jon.brisbin

Reply | Threaded
Open this post in threaded view
|

Re: node.groovy?

Remi Forax
Hi Jon,
I'm not sure that providing an async API is a good idea by itself.

I like to think that the OS/VM should issue async calls but provide
a sync-like API. Basically, when you ask for a read, the OS/VM should save the stack
as a continuation, emit the async call and when the call is finished, restart the continuation.
If your continuation is fast (VM support), you have the best of both world.
I've written a blog about that using a JVM patched with the coroutine patch.

Anyway, java 7 provides an async IO API:
http://download.java.net/jdk7/docs/api/java/nio/channels/AsynchronousChannel.html
so you can already play with it in Groovy.

Rémi

On 12/17/2010 06:06 PM, Jon Brisbin wrote:

On Dec 17, 2010, at 10:56 AM, Jochen Theodorou wrote:

but for node.js the typical usage should be from within the browser... and then I expect it not doing more than http based communication with a webserver in the end.

Certainly people use node.js for webapps heavily, but Node.js itself is a general-purpose async I/O framework. It's great for integrating messaging and whatnot as well.

What exactly is it you would want for Groovy there?

I love the Groovy language and would love to have a really lightweight, asynchronous (Closure-based) framework for developing web and other applications that could make use of all the DSLs and Java libs I'm used to without the blocking semantics of thread-based app servers.

Instead of implementing interfaces and all that, it would be great to simply pass closures. I already do something similar to this in my custom Groovy-based web framework. The difference with my framework is that it runs from a Spring MVC controller and can't make use of the higher throughput obtainable using async request processing.

Quite a bit of work? Likely. But worth it, IMHO.

Thanks!

Jon Brisbin

        Web: http://jbrisbin.com/
    Twitter: @j_brisbin
      Skype: jon.brisbin


Reply | Threaded
Open this post in threaded view
|

Re: node.groovy?

Jochen Theodorou
In reply to this post by Jon Brisbin
Jon Brisbin wrote:

>
> On Dec 17, 2010, at 10:56 AM, Jochen Theodorou wrote:
>
>> but for node.js the typical usage should be from within the browser...
>> and then I expect it not doing more than http based communication with
>> a webserver in the end.
>
> Certainly people use node.js for webapps heavily, but Node.js itself is
> a general-purpose async I/O framework. It's great for integrating
> messaging and whatnot as well.

but the keypoint is... do you communicate asynchronously with a server
or are you on the local computer only? The later goes into concurrency
and is a completely different matter. As for the first case... there is
a project for remote Closures. I guess that is what you really want..
meaning executing Closures remotely on some server.

>> What exactly is it you would want for Groovy there?
[...]
> Instead of implementing interfaces and all that, it would be great to
> simply pass closures. I already do something similar to this in my
> custom Groovy-based web framework. The difference with my framework is
> that it runs from a Spring MVC controller and can't make use of the
> higher throughput obtainable using async request processing.
>
> Quite a bit of work? Likely. But worth it, IMHO.

The key point to this is transferring the needed bytecode from the local
machine to the server, so that the server can execute that. And that is
not only a problem for Groovy, it is also one for Java. That is why for
example RMI had interfaces and implementations and all that.

And afaik there is not real good solution for that yet.

there are ways... like trying to find, based on the class, the .class
file and send it to the server. For Groovy there may be a way if we
manage to save the AST in some way... potentially the source code be
used as well... but having that reliably work in all situations is
difficult. for example getting the file is only possible if there is a
file. If we start keeping the source in memory, so we can match and send
it over the wire later, will cause big amounts of memory kept in memory.
And what if the file is precompiled? What to do for Java classes?

We want to find a solution to this for Groovy, but are missing the
bright idea

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: node.groovy?

Jon Brisbin

On Dec 17, 2010, at 12:07 PM, Jochen Theodorou wrote:

Jon Brisbin wrote:
On Dec 17, 2010, at 10:56 AM, Jochen Theodorou wrote:
but for node.js the typical usage should be from within the browser... and then I expect it not doing more than http based communication with a webserver in the end.
Certainly people use node.js for webapps heavily, but Node.js itself is a general-purpose async I/O framework. It's great for integrating messaging and whatnot as well.

but the keypoint is... do you communicate asynchronously with a server or are you on the local computer only? The later goes into concurrency and is a completely different matter. As for the first case... there is a project for remote Closures. I guess that is what you really want.. meaning executing Closures remotely on some server.

Given that async I/O is coming in JDK 7, so will need meaningful abstractions built on top of it to make it easier to use from dynamic languages like Groovy, it seems to me there's room in the Groovy community for an asynchronous framework for Groovy that handles high concurrency by invoking business logic only when triggered by an event inside the JVM. That could be data coming in from the browser and being dispatched to a waiting worker Closure or what-not in a way similar to how Node.js operates. In the context of web applications, this would give a more lightweight alternative to building small apps (like maintenance/admin apps for services or devices) that would be very similar to what Ruby users get with Sinatra (without the async part) or node.js (or webmachine, for that matter).

I wasn't really thinking about remote Closures.

jb



What exactly is it you would want for Groovy there?
[...]
Instead of implementing interfaces and all that, it would be great to simply pass closures. I already do something similar to this in my custom Groovy-based web framework. The difference with my framework is that it runs from a Spring MVC controller and can't make use of the higher throughput obtainable using async request processing.
Quite a bit of work? Likely. But worth it, IMHO.

The key point to this is transferring the needed bytecode from the local machine to the server, so that the server can execute that. And that is not only a problem for Groovy, it is also one for Java. That is why for example RMI had interfaces and implementations and all that.

And afaik there is not real good solution for that yet.

there are ways... like trying to find, based on the class, the .class file and send it to the server. For Groovy there may be a way if we manage to save the AST in some way... potentially the source code be used as well... but having that reliably work in all situations is difficult. for example getting the file is only possible if there is a file. If we start keeping the source in memory, so we can match and send it over the wire later, will cause big amounts of memory kept in memory. And what if the file is precompiled? What to do for Java classes?

We want to find a solution to this for Groovy, but are missing the bright idea

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




Thanks!

Jon Brisbin

        Web: http://jbrisbin.com/
    Twitter: @j_brisbin
      Skype: jon.brisbin

Reply | Threaded
Open this post in threaded view
|

Re: node.groovy?

Merlyn Albery-Speyer
Hey Jon,

Can you illustrate with an example of what this could look like in  
Groovy?

Cheers,
Merlyn

> Given that async I/O is coming in JDK 7, so will need meaningful  
> abstractions built on top of it to make it easier to use from  
> dynamic languages like Groovy, it seems to me there's room in the  
> Groovy community for an asynchronous framework for Groovy that  
> handles high concurrency by invoking business logic only when  
> triggered by an event inside the JVM. That could be data coming in  
> from the browser and being dispatched to a waiting worker Closure or  
> what-not in a way similar to how Node.js operates. In the context of  
> web applications, this would give a more lightweight alternative to  
> building small apps (like maintenance/admin apps for services or  
> devices) that would be very similar to what Ruby users get with  
> Sinatra (without the async part) or node.js (or webmachine, for that  
> matter).


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: node.groovy?

ld@ldaley.com
In reply to this post by Jochen Theodorou

On 18/12/2010, at 4:07 AM, Jochen Theodorou wrote:

> The key point to this is transferring the needed bytecode from the local machine to the server, so that the server can execute that. And that is not only a problem for Groovy, it is also one for Java. That is why for example RMI had interfaces and implementations and all that.
>
> And afaik there is not real good solution for that yet.
>
> there are ways... like trying to find, based on the class, the .class file and send it to the server.

This is exactly how remote control works, except it only sends over the bytecode for the closure to execute and any closures inside it. Any other classes you reference in the closures-to-execute-on-the-server must already exist there.

Groovy adds the complication though that the bytecode may not exist anywhere in an accessible form because it was actually compiled at runtime. Come to think of it, this is not unique to Groovy as you would have the same problem with cglib generated classes in straight Java I would think.



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: node.groovy?

aalmiray
In reply to this post by Jon Brisbin
Ratpack (https://github.com/bleedingwolf/Ratpack) is a Sinatra inspired, groovy based web framework :-)
12