Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-02-01:

[12:37] <ondras> so, github displays the punchcard with respect to some crappy american timezones
[12:37] <ondras> is this configurable somehow? :)
[12:42] <ashb> ondras: nope
[12:43] <ondras> okay
[13:32] <lelec_> hi, i'm looking for a scheduler for javascript server side, something like http://static.springsource.org/spring/docs/2.5.x/reference/scheduling.html in java, in common js spec, i have seen the Reactor and the Worker, which are maybe close to that
[13:35] <ashb> lelec_: cliff notes version of features?
[13:36] <lelec_> #ashb : sorry, i don't understand your question
[13:36] <ashb> what sort of things do you want in a scheduler?
[13:37] <lelec_> not much, i just want that it can handle a list of job, and check if it hard to start it or not depending on date/time, activation, ...
[13:39] <lelec_> for a starting condition, i can do it my self, what i'm looking for is the base (just an event queue, always running on the server)
[13:39] <lelec_> and i'm not sure that doing that in the web server is the good solution
[15:32] <Wes-> wait, didn't somebody actually write one of those not long ago?
[15:33] <Wes-> I thought I read about it googling for commonjs a week or so ago
[15:33] <Wes-> Too bad he left
[17:46] <devinus> hassox: why did you depricate chain?
[18:32] <devinus> isaacs: why did hassox deprecate chain in favor of your project ejsgi ?
[18:33] <isaacs> devinus: because i think he ran into some problems that jsgi solves quite nicely, and streaming jsgi solves the problems that he had with jsgi.
[18:33] <devinus> i see
[18:38] <isaacs> devinus: i can't speak for him, of course. i'm sure if you message him on gh, he'll respond :)
[18:38] <isaacs> he's in australia, though, so timezones are tricky
[18:44] <devinus> isaacs: what kind of performance does ejsgi have?
[18:44] <isaacs> devinus: so far, it's been pretty good. about 80% or so of a vanilla node server for a hello world type app.
[18:44] <isaacs> of course, if you do more with it, you start to lose perf, but tha'ts to be expected.
[18:45] <isaacs> my focus has been on the api, though.
[18:46] <devinus> isaacs: what's the benefit of using ejsgi? it only wraps http state? i'm asking b/c im looking to use a web framework or roll my own for my company
[18:47] <devinus> i watched ry's talk at js euro conf, wasnt he against using jsgi?
[18:48] <isaacs> devinus: well, jsgi is a pretty established standard with a lot of thought and effort behind it. the problem (from my pov) is that it's not async, and blocks the process while a response is being sent
[18:48] <isaacs> if you fork threads for each req, then that works, but that sucks.
[18:48] <devinus> right. i think that's why ry had a problem with it
[18:48] <isaacs> exactly
[18:48] <devinus> bleh
[18:48] <isaacs> also, from a purely aesthetic pov, i don't like that you have one kind of thing for output, and a completely different kind of thing for input.
[18:49] <isaacs> whynot just have streams for both, and then you can deal with that symmetrically.
[18:49] <isaacs> so that's what ejsgi is, and the spec is being debated in commonjs atm.
[18:49] <devinus> i see, you're just implementing what they say
[18:49] <devinus> that's noble
[18:50] <devinus> since you disagree with it
[18:50] <isaacs> haha
[18:50] <isaacs> i disagree with synchronicity and slowness, i'm not religious about API shape.
[18:51] <devinus> i'm just trying to find a microframework among the apparent hundred new web frameworks for node that just gives me some http abstraction and routing
[18:51] <devinus> plug in my own template framework
[18:52] <devinus> beginning to look like i'm going to have to roll my own
[18:52] <isaacs> devinus: if you're thinking of rolling your own, i'd take a look at ejsgi first. at the very least, you can maybe help out with it, and we're just getting started porting the existing body of jsgi middleware to the new style.
[18:52] <isaacs> it's very small at this point, basically just 4 js files.
[18:53] <isaacs> i'd be interested in knowing if it doesn't meet your needs
[18:53] <isaacs> also, (fab) is very very nice, and jed and i are both interested in pushing towards interoperability
[18:53] <devinus> (fab) looks cool
[18:53] <devinus> but
[18:53] <devinus> way too much DSL
[18:53] <isaacs> sure, i grok that
[18:53] <devinus> (for my tastes at least)
[18:54] <isaacs> ejsgi is less pretty, but also more explicit
[18:57] <devinus> the synchronicity and slowness are the only thing i have a problem with
[19:01] <isaacs> devinus: great, me too!
[19:01] <devinus> hah
[19:01] * Dantman wonders if he is completely invisible...
[19:01] <devinus> yeah, it's looking like i'll be writing my own microframework. maybe release that to github too
[19:01] <devinus> i just dont want a DSL
[19:02] <devinus> a sane router based maybe on regexes
[19:02] <devinus> pluggable template engine
[19:02] <devinus> especially since i want to use Mu
[19:02] <isaacs> Dantman: I SEE YOU!!!
[19:03] <isaacs> devinus: well, you could build that on top of ejsgi as a few middleware functions.
[19:03] <Dantman> Lies!... "HTTP-Gateway" probably doesn't ping your memory...
[19:03] <isaacs> hah
[19:03] <isaacs> i like http-gateway. but, while its deviations from jsgi's conventions are generally good, some of them also seem a bit arbitrary.
[19:04] <isaacs> it seems to me like jsgi has a fair amount of weight/support behind it already, so sticking as close to that as possible, while solving the problems it has, would be good.
[19:04] <Dantman> It's basically an inverted XmlHttpRequest
[19:04] <Dantman> And it's not meant to replace JSGI
[19:04] <isaacs> right
[19:04] <tlrobinson_> Dantman: HTTP-Gateway doesn't seem like it would work well with middleware
[19:05] <Dantman> It's meant to be a 0-level layer that the Node, JSGI, EJSGI, "<insert whatever gateway Idea you have>" can be implemented with
[19:05] <Dantman> tlrobinson_, middleware is high level... It doesn't need to understand middleware at all.
[19:06] <tlrobinson_> Dantman: personally i don't think we need anything at that level. having two different specs if just going to confuse things and reduce interoperability
[19:06] <Dantman> JSGI would be implemented in pure JS, and just use the HTTP-Gateway calls to handle the final response.
[19:06] <tlrobinson_> why though?
[19:08] <isaacs> Dantman: but jsgi is already implemented in pure JS, and uses (node|narwhal|flusspferd|whatevs) to do the final response.
[19:09] <tlrobinson_> isaacs: what do you mean by "jsgi" in that case
[19:09] <isaacs> tlrobinson_: yes, that is a bit vague, isn't it...
[19:09] <tlrobinson_> narwhal-jsc implements JSGI in C
[19:09] <isaacs> the point is that it COULD be that way.
[19:09] <tlrobinson_> sure
[19:09] <isaacs> and if a platform decides to compile it, fine.
[19:10] <Dantman> isaacs, if you implement JSGI in pure js, then you need a layer under it...
[19:10] <Dantman> The idea is to standardize that layer
[19:10] <isaacs> you could write an ejsgi.node module in C that would use node for the HTTP and build up that api in c
[19:10] <tlrobinson_> Dantman: JSGI is not difficult to implement
[19:10] <tlrobinson_> you're just adding layers uneccesarily
[19:10] <isaacs> i'm just not convinced that we need something at that level. jsgi is pretty darn simple and low-level.
[19:11] <Dantman> And the streaming issues?
[19:11] <Dantman> Or rather async
[19:11] <tlrobinson_> both the EJSGI and AJSGI proposals support async
[19:14] <tlrobinson_> Dantman: i'm not entirely opposed to some entirely different HTTP interface which is meant to be extremely low level like nodes' but it shouldn't be the way most people write HTTP applications/frameworks
[19:14] <Dantman> It's not...
[19:14] <tlrobinson_> you shouldn't be required to implement JSGI on top of it
[19:15] <Dantman> That statement applies to http but not the filesystem?
[19:15] <tlrobinson_> it's clear node is going to have something like that whether JSGI exists or not
[19:16] <tlrobinson_> i just don't really think it needs to be standardized
[19:16] <tlrobinson_> Dantman: i'm not sure what you mean
[19:17] <Dantman> "you shouldn't be required to implement JSGI on top of it"
[19:17] <Dantman> level 0 filesystem is standardized with the intention that you implement a level 1 on top of it
[19:40] <isaacs> tlrobinson_: what's AJSGI?
[19:40] <isaacs> is that kriszyp's foreach-with-promises thing?
[19:42] <tlrobinson_> yeah
[19:42] <tlrobinson_> at least that's what i've been calling it
[19:57] <Dantman> tlrobinson_, Set the MLOCk for #serverjs to "+ntcif-slk #commonjs"
[19:57] <Dantman> Apparently +f works in the MLOCK, so that'll stop the forward from being dropped
[20:07] <isaacs> my only beef with that is that the api is so unsymmetrical.
[20:08] <isaacs> stream in, stream out, seems very appealing to me
[20:08] <isaacs> but, it's pretty trivial to convert from one to another, so we could just have a show of hands, pick one for the standard, and then solve the problem with middleware if you prefer one or the other.
[20:13] <tlrobinson> oh yay http://nodejuice.com/
[20:14] <tlrobinson> took me a few minutes to realize "WSGI" here != Python's WSGI
[20:15] <evilstreak> well shit
[20:16] <evilstreak> that choice of name is pretty annoying
[20:19] <isaacs> tlrobinson: so, yeah, what exactly does "wsgi" mean there?
[20:19] <isaacs> i saw that video, too, but didn't quite grok what he was doing.
[20:20] <isaacs> some other random *sgi-like clone thing?
[20:23] <isaacs> ah, i see: http://github.com/stephenlb/nodejuice/blob/master/servers/wsgi.js
[20:24] <isaacs> yikes: (app.journey && (app.journey( req, res ) || 1)) || (rad.ran ||
[20:24] <tlrobinson> hehe
[20:24] <Dantman> Hmmm... now I want to come up with a spec to call "RINJI"...
[20:24] <tlrobinson> i often have to stop myself from being that clever
[20:25] <Dantman> heh
[20:25] <Dantman> Hmm... no wait, I need an A in there
[20:25] <isaacs> wow, this nodejuice thing sure does have a lot of marketing words...
[20:25] <Dantman> No wait... WINE doesn't have one
[20:25] <isaacs> kinda light on how to use it, though
[20:26] <hassox> devinus: I depricated it because it's not needed
[20:27] <hassox> devinus: the problems I had with jsgi have effectively been overcome with ejsgi and I'd rather have a common base to build apps on
[20:29] <devinus> hassox: ok. i was just looking at chain what seemed like the other day and thought it was cool and then was confused when i took a look at it again today
[20:29] <hassox> devinus: I didn't do it lightly ;)
[20:29] <hassox> there's only one outsanding issue, but it's an outstanding issue on both
[20:30] <hassox> it's to do with body encodings
[20:35] <nrstott> has isaacs eJSGI been ratified or voted on or anything?
[20:36] <hassox> nrstott: no i don't think so
[20:38] <tlrobinson> i'm not completely sold
[20:39] <nrstott> i like the idea, from what little ive heard of it
[20:40] <tlrobinson> i'm just not sure if it makes the async case any simpler, and it certainly makes the sync case more complicated
[20:41] <nrstott> so if today, i wnat to start working on making bogart a bit more async, what route do you suggest i take, tlrobinson ?
[20:42] <tlrobinson> nrstott: i honestly don't know. i'd probably wait until the dust settles
[20:43] <nrstott> sounds like wise advice
[20:43] <nrstott> but if i listened to that I probably never wouldve written bogart and pushed a site into production using it to begin with :)
[20:43] <tlrobinson> true :)
[20:43] <tlrobinson> i don't think you should ditch the sync support entirely
[20:44] <nrstott> maybe i can start by making my file IO async
[20:44] <nrstott> in my templating engine
[20:44] <nrstott> that doesn't gain me much though if the request still has to wait ;0
[20:46] <nrstott> there's no ratified promises standard yet either is there?
[20:46] <tlrobinson> no. and node peeps are talking about ditching promises entirely :-/
[20:46] <kriszyp_> I thought we weren't using that word (ratified) anymore ;)
[20:47] <nrstott> well node peeps have made it clear they dont really care about commonjs (ive read their mailing list)
[20:47] <nrstott> ive seen you and some others reach out to them quite a bit
[20:47] <nrstott> and not get much in return
[20:47] <nrstott> so maybe stop caring about them ;0
[20:47] <kriszyp_> I don't think node ditching promises is necessarily a bad thing, it just furthers solidifies the notion that commonjs is something that you implement on top of node, node isn't commonjs itself
[20:47] <tlrobinson> kriszyp_: that's true
[20:47] <kriszyp_> puts node in the same category as xulrunner and stuff
[20:48] <kriszyp_> it can make it easier to implement commonjs if the layer below isn't implementing it incorrectly :)
[20:48] <tlrobinson> indeed. however it does need to provide enough of a foundation to implement the CommonJS apis
[20:48] <tlrobinson> which means... synchronous IO
[20:49] <tlrobinson> or at least the ability to extend it with native modules
[20:49] <kriszyp_> I am not sure, but I thought all the file apis had sync equivalents
[20:49] <kriszyp_> I wouldn't think that would go away if they got rid of promises
[20:49] <nrstott> can't you build synch functions ontop of asynch file IO?
[20:50] <kriszyp_> nrstott: yeah, with the wait function
[20:50] <kriszyp_> so it would be important that node continue to provide access to controlling the event loop
[20:50] <tlrobinson> they're talking about removing .wait()
[20:50] <kriszyp_> wait() is implemented in js
[20:50] <tlrobinson> oh
[20:50] <kriszyp_> the important thing is the process.loop() function
[20:50] <tlrobinson> i see
[20:50] <kriszyp_> thats the hook we need to keep
[20:51] <kriszyp_> (for converting async to sync anyway)
[20:51] <nrstott> will you be losing a lot of what is good about node by putting JSGI ontop of node?
[20:52] <kriszyp_> no
[20:52] <kriszyp_> my async stuff works great on top of node
[20:52] <tlrobinson> nrstott: not with the async version of JSGI
[20:52] <nrstott> tlrobinson, does that exist?
[20:52] <kriszyp_> yes
[20:52] <tlrobinson> it's still in flux, but yes
[20:53] <nrstott> im looking to refactor bogart a bit and get it running on node
[20:53] <kriszyp_> yeah, the spec is definitely still in flux
[20:53] <kriszyp_> nrstott: http://github.com/kriszyp/jsgi-node
[20:53] <nrstott> so ifyou could point me to th right wiki or whatever, id apprecite it
[20:53] <kriszyp_> thats what you can use to run your JSGI apps on top of node
[20:53] <nrstott> kriszyp_, is that async jsgi?
[20:53] <kriszyp_> yep
[20:53] <nrstott> alrihgt many thanks
[20:53] <kriszyp_> and just fyi, after looking through it, I am definitely -1 on eJSGI
[20:53] <tlrobinson> there's also isaacs EJSGI which uses node-like streams instead of promises
[20:54] <nrstott> kriszyp_, why're you -1 on that?
[20:54] <kriszyp_> it seems inferior in everyway to what we have... except for this pause/resume functions, I think those may be useful
[20:54] <deanlandolt> kriszyp_: if that's the case there's still the matter getting the request body async in AJSGI
[20:55] <kriszyp_> yeah, but making the forEach return a promise just seems like such a better solution to that case, IMO
[20:55] <tlrobinson> kriszyp_: remind me, can you doing incremental body streaming (i.e. for comet) with your version of AJSGI?
[20:55] <deanlandolt> tlrobinson_: yes
[20:55] <kriszyp_> jsgi-node does support promises for both the response and the forEach call, so yes
[20:55] <tlrobinson> cool
[20:55] <deanlandolt> i'm looking for that pastie...it makes it pretty clear
[20:55] <kriszyp_> but that promises for the forEach has been the more controversial part that isn't on the wiki/spec or anything
[20:56] <deanlandolt> tlrobinson_: here's a kriszyp gist that shows what async streaming would look like: http://gist.github.com/289272
[20:56] <kriszyp_> do you have the rot13 example to compare it to?
[20:57] <tlrobinson> isaacs explained it at the SF SSJS meetup but i'm not sure it was correct. is the promise supposed to be fullfilled the next time you want to write, or when you want to complete / close the response?
[20:57] <kriszyp_> close the response
[20:57] <deanlandolt> kriszyp_: i still can't quite grep how lazy arrays would work though
[20:58] <tlrobinson> isaacs: is that how you understood it?
[20:58] <kriszyp_> the biggest problem with the current eJSGI is that it leads users right into buffered responses, the very thing it is trying to avoid
[21:00] <kriszyp_> fwiw, I think we could make eJSGI into something reasonable,but still with the the ability to pass in array, and have forEach work properly in the simple case is so elegant with forEachable bodies
[21:00] <tlrobinson> kriszyp_: so, returning the promise instead of the response object makes complete sense, but returning a promise from forEach feels a bit hacky. is there a logical way to explain why forEach can return a promise when it would normally just return undefined?
[21:01] <kriszyp_> because promises are creating an async version of an otherwise synchronous computation, returning a promise from a function indicates that it is not done yet
[21:01] <kriszyp_> whether it returns undefined or some more useful value is orthogonal to the issue of indicating whether it is async
[21:01] <tlrobinson> even if the result of the computation is undefined
[21:02] <tlrobinson> that makes sense
[21:02] <kriszyp_> yes, definitely, we don't put functions in a different class/syntax if they return undefined
[21:02] <kriszyp_> they are still just a function that executes and returns
[21:02] <tlrobinson> kris kowal pointed out that ref_send uses undefined for some special purpose
[21:02] <tlrobinson> but that seems like a bug
[21:02] <kriszyp_> yeah, that would seem like a bug :/
[21:03] <tlrobinson> and i think kris thought so too
[21:03] <tlrobinson> .
[21:04] <kriszyp_> the only other case of treating undefined specially that I know of, is that in dojo undefined doesn't mutate the promise/deferred in a callback
[21:04] <kriszyp_> but that isn't really apply to this situation at all
[21:04] <kriszyp_> and we don't use mutable promises anyway
[21:04] * devinus is calling his framework ElCafé
[21:10] <kriszyp_> if we did do eJSGI, the critical things that would need to be changed are that the writing function should be provided with a callback, not directly from the request (to avoid buffering), and the API needs to be written for the consumer to just see the read side, and implementor to write by implementing the read API
[21:10] <nrstott> so in JSGI 3.0 IF_NONE_MATCH is going to be ifNoneMatch ?
[21:11] <nrstott> as an example
[21:11] <nrstott> 0.3*
[21:11] <nrstott> Bogart is still depending on 0.2, trying to figure out what all i need to change
[21:11] <kriszyp_> no, it should be request.headers["if-none-match"]
[21:13] <kriszyp_> if you want some examples, you can take a look at my stuff in here: http://github.com/kriszyp/pintura/tree/master/lib/jsgi/
[21:13] <nrstott> cool
[21:13] <nrstott> looks like there's a jack 0.3 branch
[21:13] <nrstott> that should get me there cept for a few things like if-none-match
[21:14] <tlrobinson> nrstott: i dont' think anyone has committed to the 0.3 branch yet
[21:14] <deanlandolt> tlrobinson_: i've committed to my own branch but i totally tanked the line endings
[21:14] <nrstott> line endings in git are so annoying
[21:15] <nrstott> doing the normal crlf to input seems to not work for 'jack' btw, because the multipart test fixtures would be altered
[21:15] <deanlandolt> i'll redo it right and get it fixed in git...it's mostly done
[21:15] <tlrobinson> ah yeah git line endings is annoying
[21:43] <isaacs> tlrobinson: yes, that's how i understood it.
[21:43] <isaacs> if my explanation at ssjssf sounded different, then i chalk that up to my amateurish presentational skills.
[22:33] <isaacs> go make your voice heard: http://wiki.commonjs.org/wiki/JSGI/StreamExtension/vote
[22:45] <Dantman> I say stream needs a new class name...
[22:46] <Dantman> That most definitely is not the stream api I'd use in any other type of stream
[22:46] <isaacs> Dantman: if you've got a better suggestion, pitch it.
[22:46] <isaacs> as long as the question is "what should we call this thing?" i'm very very happy.
[22:46] <Dantman> JSGIStream?
[22:46] <isaacs> because that means that i'll get it.
[22:50] <isaacs> Dantman: actually, the thing is *really* called "jsgi.stream"
[22:50] <isaacs> since it hangs on request.jsgi.stream
[22:50] <Dantman> Well ok
[22:50] <Dantman> Guess I'm indifferent to the rest...
[22:50] <isaacs> there's no rule in the spec that it needs to be a top-level thing.
[22:53] * Dantman wonders how far it's been forgotten that the JS community is very good at taking ugly level 0 API and building a collection of very good quality libraries that suit different use cases very well.
[22:54] <isaacs> Dantman: yeah, that is kinda like our superpower
[22:54] <isaacs> 10 years of DOM!
[22:55] <Dantman> And that Rack is not part of Ruby
[23:19] * devinus thinking about making nodejs bindings to google's ctemplate
[23:22] <devinus> overkill
[23:22] <devinus> i need to experiment in writing bindings with node though :-/
[23:23] <devinus> hrm....
[23:26] <joshthecoder> devinus, #node.js
[23:26] <devinus> joshthecoder: thanks
[23:26] <devinus> didn't even know!
[23:26] <joshthecoder> no problem, sure they can help there
[23:28] <MisterN> he left.

 

 

Logs by date :