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

2011-01-05:

[11:32] <as-jpolo> hi all
[11:35] <as-jpolo> I have a question/remark about http://wiki.commonjs.org/wiki/JSGI/Level0/A/Draft2
[11:37] <as-jpolo> wasn't the key .scheme supposed to be .protocol instead?
[11:39] <as-jpolo> As far as I know, I always saw protocol used in javascript (ex: NodeJS, web browser, etc)
[14:37] <Wes> as-jpolo: afaik node doesn't use JSGI at all. If you're interested in the development of that draft, you should peruse the newsgroup archives, tom robinson is one name to search for
[14:44] <as-jpolo> by newsgroup are you refering to the googlegroups or something else?
[14:56] <Wes> as-jpolo: Yes
[14:57] <as-jpolo> @Wes k thanks
[15:26] <dmachi> I thought deanlandolt had updated/corrected the wiki to the latest draft or was planning on doing so, but i'm not sure if that got done yet.
[16:05] <deanlandolt> as-jpolo: what's your question re: the jsgi draft?
[16:05] <deanlandolt> and no, i haven't completely updated it but it's pretty much the same as it has been...it's just blocked by lack of progress on two fronts (binary, promises)
[16:06] <as-jpolo> hi dean
[16:06] <as-jpolo> my question was about the url related keys
[16:06] <as-jpolo> like scheme, port, etc
[16:06] <deanlandolt> yeah?
[16:07] <as-jpolo> I saw that NodeJS used dramatically different keys like protocol, pathname, hash
[16:07] <as-jpolo> so I searched why
[16:07] <deanlandolt> yeah...node likes to do that :)
[16:07] <deanlandolt> jsgi's come from the prior art of rack/wsgi
[16:07] <as-jpolo> and I figured that it was the one used by the javascript
[16:07] <deanlandolt> node's IIRC comes from browser terminology
[16:07] <as-jpolo> in javascript
[16:08] <as-jpolo> yes so my question was juste why don't we use those terminology already?
[16:08] <deanlandolt> well the location object is a browser thing, not a javascript thing
[16:08] <as-jpolo> mmm I understand
[16:08] <deanlandolt> but i think the main reason why was that nobody really advocated for that
[16:09] <as-jpolo> but it could help reuse same code
[16:09] <deanlandolt> and also that the location object may require some getter/setter stuff IIRC
[16:09] <deanlandolt> yeah...but there are bigger problems than just the names...that's why adapters are required
[16:09] <deanlandolt> (have you seen jsgi-node? it works beautifully)
[16:10] <deanlandolt> but really, IIRC the main reason we never bikeshedded those names is because we always thought there'd be a jsgi level 1 that sits on top of the level 0 draft to clean all that up
[16:10] <as-jpolo> yes I was looking for it when I came to this draft
[16:10] <deanlandolt> well it turns out there's not much we can gain from a level 1
[16:10] <as-jpolo> as you said it's pretty cool
[16:14] <as-jpolo> the matter of the names was just about conventions,which is the main goal of commonjs
[16:15] <as-jpolo> there is still the adapter pattern for everything but, that's not the spirit of conventions :-p
[16:15] <deanlandolt> agreed
[16:16] <deanlandolt> really it's just a matter of legacy...but i think modeling on the browser location object would have forced us to to do getters/setters which we were trying to avoid
[16:16] <deanlandolt> so, host vs. hostname
[16:16] <deanlandolt> oh, also i think we renamed some of them in the spirit of http 1.1
[16:17] <as-jpolo> you're referencing the Object.defineProperty use for example?
[16:18] <deanlandolt> yeah, we weren't comfortable counting on getters/setters way back when
[16:19] <as-jpolo> yeah it makes the code tricky sometimes
[16:19] <dmachi> Thanks deanlandolt, I thought you'd be able to shed some light :)
[16:20] <as-jpolo> thanks too
[17:31] <Wes> that's a good point
[17:32] <Wes> you can't specify any CommonJS interfaces which use getters/setters, until all versions of ECMAScript which do not have getters/setters are deprecated from the CommonJS standard
[17:32] <Wes> as it stands now, CommonJS platforms may be built on top of ECMA-262 Edition 3
[17:33] <Wes> and "way back when" is still "now"
[17:33] <Wes> And will likely remain "now" until IE6's browser share is below 1%
[17:48] <deanlandolt> Wes: heh, good point :)
[17:51] <oberhamsi> bettermeans: can non-members still watch everything that's going on in the project?
[17:51] <oberhamsi> sorry i don't know much about bettermeans
[17:51] <oberhamsi> dangoor, ^ ?
[17:59] <dangoor> oberhamsi: yes, the activity should all be public
[18:04] <oberhamsi> dangoor, okay, i actually registered to bettermeans & requested to join.. just to see what's going on, not wanting to vote... i guess a lot of ppl did :)
[18:05] <dangoor> the nice thing is that anyone can vote, which helps gauge interest, but only "members" have "binding" votes
[18:07] <Wes> dangoor: note that 257 and 258 are both "elect kris zup"
[18:08] <dangoor> yeah, missing kris was an oversight
[18:08] <dangoor> at the moment, there appears to be some problem with creating motions
[18:08] <dangoor> i've already filed a bug (and someone has said that they're also seeing the problem)
[18:10] <Wes> dangoor: So, a modules/2.0 proposal would be a new workstream?
[18:12] <dangoor> hmm? maybe we just have a workstream for "modules" in general
[18:13] <dangoor> https://secure.bettermeans.com/projects/829/dashboard
[19:16] <Wes> dangoor: Hey, I get a 404 for https://secure.bettermeans.com/projects/520/motions/251 - is that because it's me, or because something funny is going on?
[19:18] <dangoor> there's a problem at the moment
[19:18] <dangoor> i've filed a bug
[19:25] <Wes> dangoor - you got any idea how to attach sub-tasks to tasks?
[19:26] <Wes> like in Modules->Modules/2.0, can I create a task which is "decide if return exports is a good idea?"
[19:33] <dangoor> Wes: no idea
[19:34] <Wes> Hm, they need a "live support" guy :)
[19:42] <dangoor> i doubt it's their day jobs at this point :)
[19:49] <Wes> dangoor: that's true. But I'd pay a few dollars for a support guy to hold my hand! :)
[19:49] <dangoor> you can email them
[19:50] <dangoor> via the contact form? they actually did reply to me
[19:51] <Wes> deanlandolt: you implemented wrapped modules per the m.c.prototype.declare monkey-patch pattern, right? I found issues doing this with GPSEE, there was require-path leakage that showed up in the tests. Any change I can talk you into running the modules/2.0 test suite that ships with bravojs on your node patch?
[19:51] <Wes> dangoor: I may just do that once I finish exploring here
[20:57] <Wes> deanlandolt: welll, it's public now
[22:12] <deanlandolt> Wes: i didn't do anything with the declare monkey patch on node, no

 

 

Logs by date :