[1:00]<Wes-> Dantman: ping [1:10]<Dantman> hmmm? [1:30]<Wes-> Dantman: Is it possible to create a "hidden" wiki page for draft editing that only 2 or 3 people can see before publishing? [1:31]<Dantman> No, MediaWiki is not built for half/hidden wiki... [1:31]<Wes-> dantman: Okee doke, thanks [13:43]<Wes-> deanlandolt: you around this morning? [13:44]<deanlandolt> Wes- hey... [13:44]<deanlandolt> oh yeah, i still owe you the notes...sending now [13:44]<deanlandolt> (there ain't much to them but it may help you a little) [13:45]<Wes-> deanlandolt: awesome [13:45]<Wes-> deanlandolt: I just figured out how to get something like Loaders/B into the module.* shim technique I was talking about [13:46]<Wes-> It requires careful spec-level architecting, but I think I got it [13:46]<Wes-> all host-environment knowledge stays with require(), but different phases of module loading are overrideable [13:47]<Wes-> so, eg, you are on a script-tag environment but want to support something slightly different like an alternate transport, you can override the right module properties and suddenly your environment is XHR with per-processing or something [13:47]<Wes-> portably across multiple commonjs implementations [13:47]<Wes-> also, I figured out how to get require.async() in for free [13:47]<Wes-> (but not called that) [13:47]<Wes-> and to work in sync-mode environments cheaply [13:48]<deanlandolt> damn man [13:48]<Wes-> writing this spec after all this thought, plus writing a couple of browser-based systems, and GPSEE is really helping the implementation clarity [13:49]<Wes-> I think I can all this stuff hang together elegantly. Hopefully elegantly enough to really warrant /2.0 [13:49]<deanlandolt> so my notes are pretty much worthless at this point [13:49]<deanlandolt> just sent them though [13:49]<deanlandolt> mandatory wrapping will be a hard sell [13:49]<deanlandolt> but there are a lot of advantages, clearly [13:50]<Wes-> KrisK wants two module formats, sad to see that, not surprised, non-wrapping is nice [13:51]<Wes-> observation: unwrapped modules in #! are logical and consistent [13:51]<deanlandolt> this is clearly a 2.0 kinda bump but it would be nice to be able to brand this in such a way that it can live side by side w/ 1.x -- which i'll be using for most of my modules for the foreseeable future [13:51]<Wes-> Yeah - there is certainly no technical reason it can't live side-by-side [13:51]<deanlandolt> well there will always /be/ two module formats...everyone supports 1.x [13:51]<Wes-> Well, actually, 1.x is not really well supported on the browser [13:52]<Wes-> the dependency problem has been brushed under the carpet [13:52]<Wes-> (I come to this conclusion after writing two separate browser impls) [13:52]<deanlandolt> very true [13:52]<Wes-> require.async(), require.ensure(), etc are B.S. ways of solving the typical dependency problem [13:53]<Wes-> they should only be used where lazy-loading is absolutely necessary (not often) [13:53]<deanlandolt> scraping is ugly, and the tricks you have to pull to either /force/ a module to be eagerly fetched for the browser //require("foo") .. or bypass... require(""+"foo") are just silly [13:53]<Wes-> But, without a dependency mechanism, they must be used regularly, or all modules must be loaded at once [13:54]<deanlandolt> still, 1.x is satisfactory for a huge class of problems... [13:54]<Wes-> never mind that scraping requires a lower-performance solution (XHR) and cannot do computed dependencies [13:54]<deanlandolt> it won't go anywhere [13:54]<Wes-> computed depends ARE a big deal, esp. in a dynamic language! [13:54]<deanlandolt> :D [13:54]<deanlandolt> no doubt about that [13:54]<deanlandolt> and especially in a world where we have so many various runtimes! [13:54]<Wes-> Oh, I see 1.x living on -- I intend to keep using it for all "real work" [13:54]<Wes-> 2.x most useful for writing portable code [13:55]<deanlandolt> plus it'd some of the other deficiencies like return exports, which is big [13:55]<deanlandolt> everyone has a different way of doing that now [13:56]<Wes-> Yes. Fixing 'return exports' will make quite a few people happy [13:56]<deanlandolt> i wonder if there's a way to brand this though that isn't so controversial...perhaps the standards-track idea is in order...just to get some implementations out there [13:56]<Wes-> return constructor; [13:57]<Wes-> I wouldn't dream of calling it standard before there are two implementations, one on the browser, one on the server, and tests [13:57]<deanlandolt> well yeah, but i just mean not calling it 2.0 yet... [13:57]<deanlandolt> because that may freeze it in its tracks [13:58]<Wes-> calling it "wrapped modules" means that commonjs newcomers who aren't familiar with the technical issues will expect Modules/1.0 modules to be a way to write cross-platform code [13:58]<Wes-> "wrapped modules? I don't need those, whatever they are" [13:58]<deanlandolt> seems like everyone else is in favor of that...i still think calling authoring formats anything other than Modules is a lie [13:58]<deanlandolt> yes, that is true..but that's fixed with education [13:58]<Wes-> Yeah. "modules 2.0" is a big step, people don't want to take it [13:59]<Wes-> I think we need to, we really need a common-everywhere module format [13:59]<deanlandolt> yeah we do [13:59]<Wes-> host environments are free to implement whatever they want for the convenience of their users [13:59]<deanlandolt> alright, i have to run...i'll be back in a few hours [13:59]<Wes-> k - thanks for the notes. I'll review and make sure I didn't miss any bullets [13:59]<Wes-> I'm still at the write-many-bullets stage :) [18:14]<Wes-> Does anybody here have great interest behind Loaders/B? [18:21]<Wes-> deanlandolt: sometimes require.main seems to be the main module's id in the discussions I'm reviewing. Is main-module's-exports really the right behaviour? Besides GPSEE, where else is this implemented? [18:21]<Wes-> so, what I did for GPSEE is more like require(require.main) [18:21]<Wes-> according to http://groups.google.com/group/commonjs/browse_thread/thread/6ad5c2c3b005cb3b/5a0f17e43d347673