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

2010-04-25:

[0:11] <mikeal1> who maintains this page ?
[0:11] <mikeal1> http://commonjs.org/impl/
[0:12] <tlrobinson> Dantman?
[0:13] <Dantman> It's part of the wiki.
[0:13] <Dantman> It's not "maintained" per-se, it's automatically created by SMW based on the Implementations listed on the wiki.
[0:13] <tlrobinson> http://wiki.commonjs.org/wiki/Implementations
[0:14] <tlrobinson> if you edit that page does it update the site?
[0:14] <Dantman> ^_^ I probably need a link to the implementation creation form
[0:14] <mikeal1> awesome
[0:15] <mikeal1> i'm just trying to update to say that CouchDB implements 1.1.1
[0:15] <mikeal1> Modules/1.1.1
[0:16] <Dantman> Existing implementation?
[0:16] <Dantman> You add that information to the spec page.
[0:17] <mikeal1> yeah, it took me a bit to figure that out
[0:17] <mikeal1> there'e lots of auto-magic in all these wiki pages
[0:18] <Dantman> ^_^ that would be my obsession with not requiring entry of the same information in two different places.
[0:19] <mikeal1> it makes sense once you work it all out
[0:19] <mikeal1> the opposite thing probably happens most of the time
[0:19] <mikeal1> you add information to the right place it and it just appears everywhere
[0:20] <Dantman> ;) that would be SMW being limited by MediaWiki's obsession with page text leading to limitation in the ui that can be presented for editing.
[0:22] <Dantman> Oh crap... T_T You just bumped my overactive brain on the wiki engines idea track......
[0:23] <Dantman> LISH like feature requires for RackSpaceCloud > Add input to Implementations page > Ideas for a JS based wiki engine.....
[0:24] <Dantman> Gotta walk back down the mental stack.
[13:20] <ashb> tlrobinson: about query vs queryString. "search" is one possibility to match the location object
[19:55] * kuya_ gets popcorn
[19:56] <ashb> :)
[20:01] <ashb> i held back too
[20:01] <ashb> should have seen the first version before i deleted it
[20:05] <kuya_> i cant say i know enuff to comment properly
[20:05] <kuya_> im still trying to get my head around how any commonjs module can be used in the browser as you dont have sync require...
[20:06] <ashb> preloadingh
[20:06] <kuya_> seems to me every commonjs module should be something like requirejs does
[20:06] <ashb> or use one of the 2-3 async require proposals
[20:07] <kuya_> preloading works i guess...
[20:08] <kuya_> wouldnt it just be loads easier to have every module start module(name, requires, function() { return exports; }) ? :)
[20:08] <ashb> putting the moudle name inside the module is kinda silly
[20:09] <kuya_> ur yea - ok drop that
[20:10] <ashb> and then you look something like the transport proposals :)
[20:12] <ondras> so
[20:12] <ondras> before I go to sleep
[20:12] <ondras> let me share a quick idea
[20:12] <ondras> regarding fast finishing of a binary api
[20:12] <ondras> :
[20:13] <ondras> why don't we take some more successfull candidate (say binary/f)
[20:13] <ondras> remove everything related to encoding
[20:13] <ashb> (what's your mesaure of success?)
[20:13] <ondras> (from string, to string)
[20:13] <ondras> and ratify that minimal version as a first comlete binary.
[20:13] <ondras> this version would be very small and there would be no standardized way to create binary from string
[20:13] <ondras> and vice-versa
[20:14] <ondras> but I do not see that as an issue
[20:14] <ashb> how do you parse HTTP?
[20:14] <ashb> which is the primary use case of binary at the moment
[20:14] <ondras> http & binary?
[20:15] <ashb> an HTTP request body is binary data
[20:15] <ondras> yeah, that makes more sense
[20:15] <ashb> the headers are ascii
[20:15] <ondras> well, you return the request as an instance of ByteWhatever
[20:15] <ondras> (request body)
[20:15] <ashb> not opposed as flusspfer has the encodings module :)
[20:15] <ondras> :)
[20:15] <ondras> see, first supporter found
[20:15] <ondras> .)
[20:16] <ondras> the thing is
[20:16] <ashb> tho we don't have /f implemented yet
[20:16] <ondras> that I really see binary as the largest showstopper atm
[20:16] <ashb> no, IO is i think
[20:16] <ashb> (streams, fs etc)
[20:16] <ondras> mhm
[20:16] <ondras> there is fs-base, if I recall
[20:16] <ondras> but no streams
[20:16] <ashb> yeah
[20:17] <ondras> but no streams can be done without binary, right?
[20:17] <ashb> well text streams can if they are distinct from binary
[20:17] <ondras> hmh
[20:17] <ondras> well, I will probably post this idea of mine to the mailing list tomorrow
[20:18] * ondras is getting tired of the number of binary proposals without a clear winner
[20:18] <ashb> there seems to just be two now, B and F
[20:18] <ashb> unless i've missed some
[20:19] <ondras> even if you limit your choice to these two (which are indeed the most implemented)
[20:19] <ondras> it is still too many
[20:19] <ashb> and i think F might be nice on spidermonkey as it can use the typed arrays implemented by the moz guys for webgl buffers (i *think* anyway)
[20:19] * ondras implementd both B and F
[20:19] <ondras> and I vote for F minus encoding
[20:20] <ashb> so long as the encodings module can still work I can probably support that
[20:20] <ashb> i.e. so that there is someway in the ecosystem of going blob <-> string
[20:20] <ondras> yeah, naturally
[20:21] <ondras> btw, some version of encodings standard might be defined in terms of new prototype methods to ByteStuff and String
[20:22] <ashb> & # food
[20:24] <ondras> dtach, zzz
[21:37] <Dantman> "a lemon meringue a day, keeps the bikeshed at bay"
[21:38] <ashb> heh
[21:43] <Dantman> ^_^ it does wonders for drowsiness too...

 

 

Logs by date :