Ringobot log - RingoJS IRC channel: #ringojs on irc.freenode.net

2010-08-31:

[0:36] <ringostarr> ce88d33 Hannes Walln?fer: Consolidate AsyncResponse states
[6:54] <hannesw> good morning!
[6:55] <hannesw> earl, emilis_info, oberhamsi, tschaub, waddler FYI ringo IRC meeting starting shortly
[6:56] * oberhamsi nods
[6:57] <hannesw> don't know if you saw this, i implemented node-like AsyncResponse yesterday:
[6:57] <hannesw> http://ringojs.org/api/master/ringo/webapp/response/index.html
[6:57] <hannesw> not sure about its final name + place, let's talk about it today
[6:58] <oberhamsi> yep, didn't look at it closely yet
[6:58] <hannesw> I don't think this will be a "mainstream" feature, more a special purpose device for implementing comet/ajax features
[6:59] <hannesw> but we don't need it to make ordinary requests fast like node.js (because threads work well for us)
[7:02] <hannesw> I've written up some agenda: http://ringojs.org/wiki/IRC_Meeting/
[7:02] <hannesw> feel free to add your own items
[7:03] <hannesw> hey zumbrunn
[7:03] <zumbrunn> good morning :-)
[7:04] <hannesw> so let's start - 0.6 delay
[7:04] <hannesw> well from my pov it's a good thing, because we've been gaining steam
[7:05] <hannesw> and added some significant features, and it's good that this happened before 0.6
[7:05] <oberhamsi> AsyncResponse abstracts away the continuations very nicely .. i like it
[7:05] <hannesw> yeah. the nice thing is you can use it synchronously, asynchronously, or mixed - and there's no performance hit at all
[7:06] <hannesw> so if you don't use it asynchronously, there's no continuation in there at all
[7:06] <oberhamsi> nice
[7:07] <hannesw> and you can do anything from instant responses to hour-long streams
[7:07] <hannesw> what I'm not sure about is "positioning", i.e. if this should be in a dedicated module
[7:07] <oberhamsi> yep, so just return AsyncResponse, hold a reference to it.. and write() whenever and as long as you want
[7:08] <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
[7:08] <hannesw> not sure the current module structure / API doc reflects this enough
[7:09] <hannesw> Originally, it was called Response.stream() but that wasn't clear enough IMO
[7:10] <hannesw> especially since it returns an object that is very different from Response
[7:10] <oberhamsi> hm..
[7:10] <hannesw> if you have an idea about naming/module naming... let's hear about it
[7:11] <hannesw> another reason why this might be a dedicated module is I think it won't be very useful in "ordinary" web apps
[7:11] <hannesw> there's not much point in using it unless you really need long delays, or multiple write events, or both
[7:16] <hannesw> FYI, here's a very simple example of AsyncResponse:
[7:16] <hannesw> http://gist.github.com/558718
[7:18] <hannesw> run with ringo-web streaming-async.js
[7:19] <hannesw> so, onwards
[7:19] <hannesw> what I wanted to talk about, other than naming, is this in the context of comet strategy
[7:20] <hannesw> So until recently, I had thought that ringo-cometd was the answer to most of our comet/advanced ajax needs
[7:21] <hannesw> but I've come to conclusion that cometd/bayeux is a bit of a solution looking for a problem
[7:21] <hannesw> and simply too much for many use cases
[7:21] <oberhamsi> hehe
[7:21] <oberhamsi> i too feel websockets do the most sensible subset of what you can do with cometd
[7:22] <hannesw> also see this discussion (long): http://cometdaily.com/2008/02/07/colliding-comets-battle-of-the-bayeux-part-1/
[7:22] <oberhamsi> the advantage of cometd being you can use it right now, websockets.. not so much. or are there - flash? - workarounds for IE / opera?
[7:23] <hannesw> oberhamsi right. and for those browsers that don't support websocket, somethign like Socket.IO makes much more sense
[7:23] <hannesw> http://github.com/LearnBoost/Socket.IO
[7:23] <hannesw> this provides functionality similar to websocket, and uses whatever the browser/server support
[7:24] <oberhamsi> oh right, didn't see it like that.
[7:24] <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
[7:25] <hannesw> So both the WebSocket support and the AsyncResponse thing I did are in this context.
[7:25] <hannesw> I want ringo to be able to implement all those various comet transports
[7:25] <oberhamsi> not bad.. and they have the clientside lib for abstracting that away
[7:25] <hannesw> here's the node.js server side impl: http://github.com/LearnBoost/Socket.IO-node/
[7:26] <hannesw> and writing a Socket.IO-ringo should now be very easy.
[7:27] <hannesw> here's the transports it supports: http://github.com/LearnBoost/Socket.IO-node/tree/master/lib/socket.io/transports/
[7:28] <hannesw> so that's basically it
[7:29] <oberhamsi> i'll have to play with this stuff to see how it all fits together
[7:29] <hannesw> yeah, me too :)
[7:29] <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? :)
[7:30] <hannesw> Socket.IO provides a much nicer abstraction
[7:31] <hannesw> you get basically a WebSocket API in the browser and don't have to care about making XHR requests
[7:31] <hannesw> and the same on the server, of course
[7:31] <hannesw> so instead of writing responses, you just send and receive packets
[7:31] <hannesw> or messages
[7:32] <oberhamsi> ah i see! that was my disconnect... Socket.IO is the same on server & browser and this is especially important for the browser
[7:32] <oberhamsi> so it's like WebSockets, but works right now
[7:33] <hannesw> right
[7:34] <oberhamsi> no surprise the node people love it
[7:34] <hannesw> i also saw that i think a majority of nodeknockout entries seemed to use socket.io
[7:34] <hannesw> that kind of flipped the switch with me
[7:34] <oberhamsi> so how would you summarize your "realtime web story" ?
[7:34] <hannesw> cometd/bayeux woudn't have worked for most of these, or would have complete overkill
[7:35] <hannesw> oberhamsi i think Socket.IO should/could become an important part of it
[7:35] <hannesw> and I'd say we can be "like node.js, but simpler"
[7:36] <oberhamsi> hehe okay
[7:38] * oberhamsi afk 5
[7:38] <hannesw> hi robi42
[7:38] <robi42> hi
[7:38] <hannesw> sorry, meeting is mostly over i think :)
[7:39] <hannesw> at least I'm through with my topics
[7:39] <robi42> ah ok, reading up on logs :)
[7:39] <hannesw> http://ringojs.org/wiki/IRC_Meeting/
[7:39] <hannesw> the news is WebSocket and AsyncResponse (committed yesterday evening)
[7:40] <robi42> seen it, very cool
[7:40] <hannesw> and how they fit in the context of a possible new comet/ajax strategy
[7:41] <robi42> something which would be awesome is, basically, websockets support incl. fallback mechanism
[7:41] <hannesw> yes, that's my vision, too
[7:41] <hannesw> and we already have the client side lib for that, which is Socket.IO
[7:42] <robi42> sweet
[7:42] <hannesw> socket.IO-node seems relatively simple to port/implement in ringo
[7:42] <hannesw> http://github.com/LearnBoost/Socket.IO-node/
[7:43] <robi42> looks good
[7:43] <hannesw> hm, the more i think about it the more i feel AsyncResponse should be in its own module, like ringo/webapp/async
[7:45] <robi42> together with socket.io-ringo?
[7:45] <oberhamsi> ah we still have the 0.6 topic :)
[7:46] <robi42> or where's that gonna end up?
[7:46] <hannesw> i think socket.io-ringo should be its own package
[7:46] <robi42> ok
[7:46] <hannesw> it's not a "standard" like HTTP/Websockets
[7:46] <hannesw> I also think ringo-webapp should be a separate package eventually
[7:46] <hannesw> maybe in 0.7
[7:47] <robi42> yes, decoupling webapp from core would be nice
[7:47] <hannesw> but package handling must improve for that to happen IMO
[7:47] <robi42> i.e., dependency resolution support?
[7:48] <hannesw> well, some kind of version control
[7:48] <hannesw> i.e. don't install ringo-webapp 0.7 with ringo 0.6.*
[7:48] <robi42> i see, yes
[7:50] <robi42> so, how's the "schedule" for 0.6 looking now? mid sept.? :)
[7:50] <hannesw> yes
[7:50] <hannesw> we're on holiday for a week, starting probably tomorrow
[7:51] <hannesw> i think that's a good timeframe to let the new features burn in
[7:51] <robi42> as written before, i also prefer to have some delays regarding 0.6 release but some really useful new/overhauled features done
[7:51] <hannesw> fix bugs, clear up namespacing, etc
[7:51] <robi42> yep
[7:51] <robi42> makes sense
[7:51] <hannesw> I'm sometimes too eager/optimistic with that :)
[7:51] <robi42> hehe
[7:52] <hannesw> afk making coffee
[7:52] <robi42> coffee time as well :)
[8:16] <hannesw> opinions regarding AsyncResponse naming?
[8:17] <hannesw> i mean module name + class name
[8:20] <robi42> ringo/webapp/response -> Response, ringo/webapp/asyncresponse -> AsyncResponse?
[8:23] <oberhamsi> i like it in webapp/response... i doubt anyone will confuse it with a normal JSGI response
[8:24] <oberhamsi> hm, you can't use it the same way... okay that is confusing.
[8:29] <hannesw> ringo/webapp/async?
[8:57] <earl> (very nice, this AsyncResponse)
[9:11] <zumbrunn> ringo/webapp/response -> Response, ringo/webapp/async -> Response ?
[9:28] <ringostarr> 14c33e9 Hannes Walln?fer: Allow ringo/subprocess methods to specify environment variables and directory to run in
[9:30] <hannesw> zumbrunn I would have thought ringo/webapp/async -> AsyncResponse
[9:30] <hannesw> earl thanks!
[9:54] <ringostarr> 9e610d5 Hannes Walln?fer: Improve jsdoc in ringo/subprocess
[9:55] <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
[9:55] <hannesw> oberhamsi yeah... fits right in with the new options argument!
[9:55] <oberhamsi> ah!
[9:56] <oberhamsi> great, currently i have my own bsubprocess.js which just doesn't wrap everything as TextStream
[9:56] <hannesw> feel free to implement it, otherwise I will after lunch :)
[9:56] <hannesw> afk
[10:43] <hannesw> so should i go for the binary subprocess?
[10:43] <hannesw> i guess error stream should always be text?
[11:00] <oberhamsi> i didn't touch it yet.. gotta work for the man
[11:01] <oberhamsi> error as text.. works for my cases.
[12:28] <ringostarr> 564c014 Hannes Walln?fer: Major overhaul of ringo/subprocess.
[12:29] <hannesw> oberhamsi major overhaul of subprocess module:
[12:29] <hannesw> http://ringojs.org/api/master/ringo/subprocess/index.html
[12:30] * oberhamsi looks at it
[12:30] <hannesw> there's now a low-level createProcess() function that give pretty much full control over the process
[12:30] <hannesw> let me know if you're happy with it
[12:31] <oberhamsi> looks good, i'll try it.
[12:35] <oberhamsi> thanks for overhaul.. now i get how to use connect ;)
[12:36] <hannesw> one issue is that connect() also waits until process is done (that's not documented)
[12:46] <hannesw> anyway, should be a step up from the previous version :)
[13:05] <oberhamsi> definitely!
[16:39] <oberhamsi> :) rhino pic made reddit front http://www.reddit.com/r/pics/comments/d7oav/never_give_up_on_your_dreams/
[16:56] <robi42_> lol
[23:40] <ringostarr> 60568ed Hannes Walln?fer: Simplify