Logs for the RingoJS IRC channel, as logged by ringostarr.

2010-08-31

[09:57] <hannesw> good morning!

[09:58] <hannesw> earl, emilis_info, oberhamsi, tschaub, waddler FYI ringo IRC meeting starting shortly

[09:59] * oberhamsi nods

[10:00] <hannesw> don't know if you saw this, i implemented node-like AsyncResponse yesterday:

[10:00] <hannesw> http://ringojs.org/api/master/ringo/webapp/response/index.html

[10:00] <hannesw> not sure about its final name + place, let's talk about it today

[10:01] <oberhamsi> yep, didn't look at it closely yet

[10:02] <hannesw> I don't think this will be a "mainstream" feature, more a special purpose device for implementing comet/ajax features

[10:02] <hannesw> but we don't need it to make ordinary requests fast like node.js (because threads work well for us)

[10:05] <hannesw> I've written up some agenda: http://ringojs.org/wiki/IRC_Meeting/

[10:05] <hannesw> feel free to add your own items

[10:06] <hannesw> hey zumbrunn

[10:06] <zumbrunn> good morning :-)

[10:07] <hannesw> so let's start - 0.6 delay

[10:08] <hannesw> well from my pov it's a good thing, because we've been gaining steam

[10:08] <hannesw> and added some significant features, and it's good that this happened before 0.6

[10:08] <oberhamsi> AsyncResponse abstracts away the continuations very nicely .. i like it

[10:09] <hannesw> yeah. the nice thing is you can use it synchronously, asynchronously, or mixed - and there's no performance hit at all

[10:09] <hannesw> so if you don't use it asynchronously, there's no continuation in there at all

[10:09] <oberhamsi> nice

[10:10] <hannesw> and you can do anything from instant responses to hour-long streams

[10:10] <hannesw> what I'm not sure about is "positioning", i.e. if this should be in a dedicated module

[10:10] <oberhamsi> yep, so just return AsyncResponse, hold a reference to it.. and write() whenever and as long as you want

[10:11] <hannesw> basically, there's JSGI, which is all the other responses (including async JSGI via promise), and then there's AsyncResponse which is completely different

[10:11] <hannesw> not sure the current module structure / API doc reflects this enough

[10:12] <hannesw> Originally, it was called Response.stream() but that wasn't clear enough IMO

[10:13] <hannesw> especially since it returns an object that is very different from Response

[10:13] <oberhamsi> hm..

[10:13] <hannesw> if you have an idea about naming/module naming... let's hear about it

[10:14] <hannesw> another reason why this might be a dedicated module is I think it won't be very useful in "ordinary" web apps

[10:14] <hannesw> there's not much point in using it unless you really need long delays, or multiple write events, or both

[10:20] <hannesw> FYI, here's a very simple example of AsyncResponse:

[10:20] <hannesw> http://gist.github.com/558718

[10:21] <hannesw> run with ringo-web streaming-async.js

[10:22] <hannesw> so, onwards

[10:22] <hannesw> what I wanted to talk about, other than naming, is this in the context of comet strategy

[10:23] <hannesw> So until recently, I had thought that ringo-cometd was the answer to most of our comet/advanced ajax needs

[10:24] <hannesw> but I've come to conclusion that cometd/bayeux is a bit of a solution looking for a problem

[10:24] <hannesw> and simply too much for many use cases

[10:24] <oberhamsi> hehe

[10:25] <oberhamsi> i too feel websockets do the most sensible subset of what you can do with cometd

[10:25] <hannesw> also see this discussion (long): http://cometdaily.com/2008/02/07/colliding-comets-battle-of-the-bayeux-part-1/

[10:25] <oberhamsi> the advantage of cometd being you can use it right now, websockets.. not so much. or are there - flash? - workarounds for IE / opera?

[10:26] <hannesw> oberhamsi right. and for those browsers that don't support websocket, somethign like Socket.IO makes much more sense

[10:26] <hannesw> http://github.com/LearnBoost/Socket.IO

[10:26] <hannesw> this provides functionality similar to websocket, and uses whatever the browser/server support

[10:27] <oberhamsi> oh right, didn't see it like that.

[10:27] <hannesw> it uses websocket if the broser supports it, and otherwise flash sockets or various XHR schemes. and it's quckly become the standard cometd impl for node.js

[10:28] <hannesw> So both the WebSocket support and the AsyncResponse thing I did are in this context.

[10:28] <hannesw> I want ringo to be able to implement all those various comet transports

[10:28] <oberhamsi> not bad.. and they have the clientside lib for abstracting that away

[10:29] <hannesw> here's the node.js server side impl: http://github.com/LearnBoost/Socket.IO-node/

[10:29] <hannesw> and writing a Socket.IO-ringo should now be very easy.

[10:30] <hannesw> here's the transports it supports: http://github.com/LearnBoost/Socket.IO-node/tree/master/lib/socket.io/transports/

[10:31] <hannesw> so that's basically it

[10:32] <oberhamsi> i'll have to play with this stuff to see how it all fits together

[10:32] <hannesw> yeah, me too :)

[10:32] <oberhamsi> though why do i have to drop down to Socket.IO when dealing with non-websocket transports.. can't AsyncResponse deal with that for me? :)

[10:33] <hannesw> Socket.IO provides a much nicer abstraction

[10:34] <hannesw> you get basically a WebSocket API in the browser and don't have to care about making XHR requests

[10:34] <hannesw> and the same on the server, of course

[10:34] <hannesw> so instead of writing responses, you just send and receive packets

[10:35] <hannesw> or messages

[10:35] <oberhamsi> ah i see! that was my disconnect... Socket.IO is the same on server & browser and this is especially important for the browser

[10:36] <oberhamsi> so it's like WebSockets, but works right now

[10:36] <hannesw> right

[10:37] <oberhamsi> no surprise the node people love it

[10:37] <hannesw> i also saw that i think a majority of nodeknockout entries seemed to use socket.io

[10:37] <hannesw> that kind of flipped the switch with me

[10:37] <oberhamsi> so how would you summarize your "realtime web story" ?

[10:37] <hannesw> cometd/bayeux woudn't have worked for most of these, or would have complete overkill

[10:38] <hannesw> oberhamsi i think Socket.IO should/could become an important part of it

[10:38] <hannesw> and I'd say we can be "like node.js, but simpler"

[10:39] <oberhamsi> hehe okay

[10:41] * oberhamsi afk 5

[10:41] <hannesw> hi robi42

[10:41] <robi42> hi

[10:41] <hannesw> sorry, meeting is mostly over i think :)

[10:42] <hannesw> at least I'm through with my topics

[10:42] <robi42> ah ok, reading up on logs :)

[10:42] <hannesw> http://ringojs.org/wiki/IRC_Meeting/

[10:42] <hannesw> the news is WebSocket and AsyncResponse (committed yesterday evening)

[10:43] <robi42> seen it, very cool

[10:43] <hannesw> and how they fit in the context of a possible new comet/ajax strategy

[10:44] <robi42> something which would be awesome is, basically, websockets support incl. fallback mechanism

[10:44] <hannesw> yes, that's my vision, too

[10:44] <hannesw> and we already have the client side lib for that, which is Socket.IO

[10:45] <robi42> sweet

[10:45] <hannesw> socket.IO-node seems relatively simple to port/implement in ringo

[10:45] <hannesw> http://github.com/LearnBoost/Socket.IO-node/

[10:46] <robi42> looks good

[10:46] <hannesw> hm, the more i think about it the more i feel AsyncResponse should be in its own module, like ringo/webapp/async

[10:48] <robi42> together with socket.io-ringo?

[10:49] <oberhamsi> ah we still have the 0.6 topic :)

[10:49] <robi42> or where's that gonna end up?

[10:49] <hannesw> i think socket.io-ringo should be its own package

[10:49] <robi42> ok

[10:49] <hannesw> it's not a "standard" like HTTP/Websockets

[10:49] <hannesw> I also think ringo-webapp should be a separate package eventually

[10:50] <hannesw> maybe in 0.7

[10:50] <robi42> yes, decoupling webapp from core would be nice

[10:50] <hannesw> but package handling must improve for that to happen IMO

[10:51] <robi42> i.e., dependency resolution support?

[10:51] <hannesw> well, some kind of version control

[10:51] <hannesw> i.e. don't install ringo-webapp 0.7 with ringo 0.6.*

[10:51] <robi42> i see, yes

[10:53] <robi42> so, how's the "schedule" for 0.6 looking now? mid sept.? :)

[10:53] <hannesw> yes

[10:53] <hannesw> we're on holiday for a week, starting probably tomorrow

[10:54] <hannesw> i think that's a good timeframe to let the new features burn in

[10:54] <robi42> as written before, i also prefer to have some delays regarding 0.6 release but some really useful new/overhauled features done

[10:54] <hannesw> fix bugs, clear up namespacing, etc

[10:54] <robi42> yep

[10:54] <robi42> makes sense

[10:54] <hannesw> I'm sometimes too eager/optimistic with that :)

[10:55] <robi42> hehe

[10:55] <hannesw> afk making coffee

[10:56] <robi42> coffee time as well :)

[11:20] <hannesw> opinions regarding AsyncResponse naming?

[11:20] <hannesw> i mean module name + class name

[11:23] <robi42> ringo/webapp/response -> Response, ringo/webapp/asyncresponse -> AsyncResponse?

[11:27] <oberhamsi> i like it in webapp/response... i doubt anyone will confuse it with a normal JSGI response

[11:27] <oberhamsi> hm, you can't use it the same way... okay that is confusing.

[11:32] <hannesw> ringo/webapp/async?

[12:00] <earl> (very nice, this AsyncResponse)

[12:14] <zumbrunn> ringo/webapp/response -> Response, ringo/webapp/async -> Response ?

[12:33] <hannesw> zumbrunn I would have thought ringo/webapp/async -> AsyncResponse

[12:33] <hannesw> earl thanks!

[12:58] <oberhamsi> re: subprocess. i think i mentioned that before.. binary data. if you work with imagemagik or graphviz in my case i need to get/pass binary data to subprocesses

[12:58] <hannesw> oberhamsi yeah... fits right in with the new options argument!

[12:58] <oberhamsi> ah!

[12:59] <oberhamsi> great, currently i have my own bsubprocess.js which just doesn't wrap everything as TextStream

[12:59] <hannesw> feel free to implement it, otherwise I will after lunch :)

[12:59] <hannesw> afk

[13:46] <hannesw> so should i go for the binary subprocess?

[13:47] <hannesw> i guess error stream should always be text?

[14:04] <oberhamsi> i didn't touch it yet.. gotta work for the man

[14:04] <oberhamsi> error as text.. works for my cases.

[15:32] <hannesw> oberhamsi major overhaul of subprocess module:

[15:32] <hannesw> http://ringojs.org/api/master/ringo/subprocess/index.html

[15:33] * oberhamsi looks at it

[15:33] <hannesw> there's now a low-level createProcess() function that give pretty much full control over the process

[15:33] <hannesw> let me know if you're happy with it

[15:34] <oberhamsi> looks good, i'll try it.

[15:38] <oberhamsi> thanks for overhaul.. now i get how to use connect ;)

[15:39] <hannesw> one issue is that connect() also waits until process is done (that's not documented)

[15:49] <hannesw> anyway, should be a step up from the previous version :)

[16:08] <oberhamsi> definitely!

[19:42] <oberhamsi> :) rhino pic made reddit front http://www.reddit.com/r/pics/comments/d7oav/never_give_up_on_your_dreams/

[20:00] <robi42_> lol