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

2009-10-25:

[15:26] <ashb> enodean
[15:26] <ashb> bah
[15:52] <ashb> deanlandolt: aha.
[15:52] <ashb> so remoteUser etc i'm not going to bother with
[15:52] <ashb> nor remoteHost as i have remoteAddr
[15:53] <ashb> and i can't be bothered to resolve it :)
[15:54] <deanlandolt> ashb: i don't think it even matters :)
[15:54] <ashb> cool :)
[15:54] <deanlandolt> i think remoteAddr should be required
[15:55] <deanlandolt> or rather, at least encouraged
[15:55] <deanlandolt> everything else is just kinda cgi-specific
[15:55] <deanlandolt> speaking of, i need to finish that damn draft...shite
[15:56] <ashb> http://pastie.org/669019
[15:56] <ashb> so thats the raw env from Zest
[15:56] <deanlandolt> sexy
[15:57] <ashb> looks right?
[15:57] <deanlandolt> http 1.0? really?
[15:57] <deanlandolt> looks right otherwise, yeah
[15:58] <ashb> thats cos i did it manually via telnet
[15:58] <deanlandolt> ah...nice
[15:58] <deanlandolt> so you're not multiprocess or multithreaded?
[15:58] <deanlandolt> how do you handle concurrent requests?
[15:59] <ashb> its async.
[15:59] <ashb> its only designed as a development test server
[16:00] <deanlandolt> cool
[17:01] <humbletim> my latest hypothesis: all javascript (or JSON) strings with neither parenthesis nor equals (ie: they do not match /[()=]/) are safe to directly eval
[17:04] <ondras> what if I define a getter and access that property in a JSON string?
[17:04] <humbletim> then your getter has side effects ;) but you're right, would have to qualify it that way
[17:46] <ashb> humbletim: not really.
[17:46] <ashb> "foo = undefined"; would still break things
[17:46] <ashb> depends on your value of safe
[17:46] <humbletim> ashb: well, equals sign is precluded
[17:47] <ashb> ah true
[17:47] <ashb> but still why would you want to?
[17:49] <Wes-> fwiw crock publishes a JSON validation regexp
[17:50] <humbletim> ashb: wanted a inlined cross-VM way of throwing up (and consuming) JSON via new Error(jsonstring)
[17:50] <ashb> JSON.parse
[17:50] <humbletim> ashb: not cross-VM yet ;)
[17:51] <ashb> http://www.JSON.org/json2.js
[17:51] <ashb> now it is
[17:51] <Wes-> right-o
[17:52] <humbletim> ashb: hehe, by inlined i also meant zerodeps. json2.js is pretty heavy
[17:52] <humbletim> (to be passing around on the wire, for example)
[17:52] <Wes-> humbletim: http status 304
[17:53] <humbletim> Wes-: don't have HTTP either tho
[17:54] <ashb> humbletim: JSON is part of ES5
[17:54] <ashb> so all commonJS envs should have it
[17:56] <humbletim> ashb: Wes-: well, this is for another crazy experiment, so admittedly i'm in outer space, but don't want to assume anything about the VM at all really, except that it's less than 5 years old maybe.
[17:57] <Wes-> humbletim: then pare down json2.js - it's 80% comments anyhow!
[18:03] <humbletim> Wes-: hmm, not quite scary enough for me. it's nearly Halloween here! and i'm really growing fond of this: new Error(''+function() { return JSON.stringify({ fatal: true }); }) as a syntax-checkable cross-VM encoding mechanism. the catching side then has lots of options for getting at the JSON payload, but no strict dependencies except for string mangling
[18:24] <humbletim> so per modules 1.1. then, fs-base might become fsBase?
[18:24] <ashb> no i dont think so - why/
[18:24] <ashb> or rather, what says/gave you the impression it would
[18:24] <humbletim> http://wiki.commonjs.org/wiki/Modules/1.1#Module_Identifiers
[18:25] <ashb> who the fuck added that
[18:25] <ashb> cos its wrong
[18:25] <humbletim> well, it's a draft after all no? ;)
[18:26] <ashb> so that just got copied over from 1.0
[18:27] <ashb> seems like its always just been there, but never used
[18:27] <ashb> or rather, no one uses camelCase modules names
[18:28] <humbletim> i think it has potential to be a good thing, but really don't have a preference yet. i'll support both and interconvert for now. ;)
[18:29] <humbletim> i like the concept maybe because camelCase is subset of valid paths, but not the other way around (fs-base necessarily has to be referenced by some other name)
[18:29] <ashb> i've changed it
[18:29] <ashb> camelCase isn't wrong
[18:30] <ashb> but it's alsot needlessly restrictive
[18:30] <ashb> A term must match the following regexp: /^\.{1,2}|[a-z0-9-_]$/i
[18:31] <humbletim> put the hyphen first and i'm happy enough. /^\.{1,2}|[-a-z0-9_]$/i
[18:31] <ashb> also +
[18:31] <humbletim> oh, but i just renamed everything to single letters!
[18:32] <Dantman> ;) /^\.{1,2}$|^[-a-z0-9_]$/i
[18:32] <ashb> /^(?:\.{1,2}|[-a-z0-9_]+)$/i
[18:32] <ashb> /^(?:\.{1,2}|[-a-z0-9_]+)$/i
[18:33] <ashb> is how it now stands
[18:38] <humbletim> hmm, since "paths" implies a strong relationship to host's filesystem, why not allow any valid path chars for module ids? or, enforce same character classes for "paths"?
[18:38] <humbletim> (at least terms within paths)
[18:39] <ashb> humbletim: cos valid path chars change quite a bit from OS to OS
[18:39] <ashb> that minimal subset should 1) work everywhere and 2) be useful/expressive enough
[18:39] <Dantman> Rather, FS to FS
[18:40] <ashb> fs to fs too
[18:51] <humbletim> ok, so regurgitating back then: elements of require.paths are only limited by the os/native filesystem conventions. beneath each of those paths, all (require-able) .js file names and sub-directories between must be valid module ids. ?
[18:54] <ashb> yeah sounds about right
[18:54] <humbletim> i'm starting to think the require.paths paradigm may be too dependent on literal filesystem-based module loaders
[18:55] <ashb> it is.
[18:55] <ashb> its optional
[18:56] <humbletim> how could a module author actually make use of it, without more commonjs-container sniffing code?
[18:59] <ashb> so only app writers should care about paths
[18:59] <ashb> and maybe not even then
[18:59] <ashb> modules should be self containtes
[19:02] <ashb> i've certainly be writing apps that just use '../lib/foo' etc
[19:03] <humbletim> since require.paths (if supported) is a super-global, securing it sounds like a very mystical challenge
[19:07] <humbletim> since it's implementation-specific, maybe it can just be a well-known module name instead of attribute. like, require("fs"); var rp = require("require-paths"); rp.unshift(fs.canonical("./wrappers"));
[19:31] <ashb> require.paths is just like perls @INC or pythons sys.paths
[19:32] <ashb> securing it is almost a side issue to its common use
[19:32] <humbletim> so why bake in security like that?
[19:33] <humbletim> i mean, why specify require.paths at all and those interesting properties? (like super-global-ness) ?
[19:34] <ashb> what security?
[19:34] <ashb> the module names aren't security - they are more portability
[19:49] <humbletim> my understanding is that in perl @INC elements are os-specific, module names always map to the literal filesystem, and inlined relative references are impossible; same goes for python, right?
[19:51] <ashb> 1) require.paths is os specific anyway
[19:51] <ashb> 2) perl modules are [a-z][a-z0-9_]+
[19:51] <ashb> (/i too)
[19:56] <humbletim> ok, it's starting to make sense now. so: a "portable" module is a module that can be loaded against a fixated set of module loader implementations (for example: filesystem-backed). other implementations can later start to emulate the first most-common practices, just like browsers did with XMLHttpRequest
[20:01] <ashb> yeah
[20:01] <ashb> the restrictions on module names are to make it possible to be portable to FSes/OSes and to make it possible to be secured
[20:02] <ashb> i.e. modules dont have to live on disk
[20:05] <ashb> and require.paths doesn't have to be obeyed
[20:07] <humbletim> gotcha. i was looking to "require" as an application-level construct, but limiting it to the framework/bootstrap layers is fine. application/frameworks in the past have all had their own custom-fitted module loader paradigms too
[20:26] <humbletim> i can see myself building in terms of "autonomous" modules (no dependencies beyond the exports object existing), "partial" modules (having one or more, possibly abstract dependencies to be resolved somehow), and "subordinate" modules (tied to a particular implementation).
[20:30] <ashb> yeah, there's been some discussion of how to get packages of modules working nicely
[20:31] <ashb> nothing has come out as a clear winner yet
[20:31] <ashb> and it might not have to
[20:32] <ashb> since the package manager can be a module which oyu require
[20:32] <ashb> var P = require('my-package-mgr');
[20:32] <ashb> P.load('.....')
[20:32] <ashb> or some such
[20:32] <ashb> (which is sort of the approach gems has taken)
[20:43] <humbletim> for now i'm going to only permit JSGI app's to do module loading during initialization/construction by way of a ref = require(). i'm trying to avoid loading modules as a side-effect of individual JSGI requests. thoughts?
[20:44] <ashb> i can see why you'd want that
[20:44] <ashb> it wont every be forbidden by the spec tho
[20:44] <ashb> so sure, do it if you want
[20:44] <humbletim> i think i have to in order to produce portable JSGI
[20:45] <ashb> er... why?
[20:46] <humbletim> because module loading happens at the container's implementation layer
[20:46] <ashb> and?
[20:46] <ashb> I feel one of us missing somethign in this conversation. not sure who
[20:46] <humbletim> it's like a CGI script asking Apache for an MD5 module, no?
[20:47] <Wes-> humbletim: no, it's like a CGI C program loading libmd5.so
[20:47] <Wes-> Or a perl CGI using something from CPAN
[20:47] <humbletim> Wes-: i disagree -- a CGI script has no way to ask it's container for functionality
[20:48] <Wes-> humbletim: ????
[20:48] <Wes-> have you ever written a CGI program?
[20:48] <humbletim> container being Apache, etc.
[20:48] <ashb> its not asking its container
[20:48] <ashb> its asking its interpreter
[20:48] <Wes-> why would it need to ask apache?
[20:48] <Wes-> just load it off the disk and run it
[20:49] <humbletim> sigh, that's insecure. and JSGI is becoming much more difficult than CGI
[20:49] <Wes-> humbletim: so implement security
[20:49] <Wes-> module jails, JSPrincipals, lots of ways
[20:49] <humbletim> Wes-: right -- but how to do that at the "require" layer?
[20:49] <Wes-> humbletim: well, that depends on how you implemented require
[20:50] <Wes-> you could use JSPrinciples
[20:50] <humbletim> but my JSGI application _doesnt_ implement it
[20:50] <Wes-> or you could use "strcmp"
[20:50] <humbletim> the container must
[20:50] <Wes-> humbletim: apache is not running your javascript, surely
[20:50] <Wes-> I thought you were using spidermonkey
[20:50] <humbletim> Wes-: say i run a vhost server. it's one big apache process. i let my users do cgi-bin
[20:51] <humbletim> Wes-: what is the analogous setup for JSGI?
[20:51] <Wes-> if (strncmp(module_path, attempted_load_path) != 0)
[20:51] <Wes-> return JS_FALSE;
[20:51] <Wes-> This has nothing at all to do with JSGI
[20:51] <Wes-> it has to do with implementing a secureable require()
[20:51] <humbletim> but CGI is not dependent on Apache. by making JSGI dependent on spidermonkey, why have JSGI at all?
[20:51] <ashb> flusspferd has a security::check_file() method for just that purpose
[20:52] <Wes-> humbletim: WSGI is dependent on python
[20:52] <Wes-> I don't see a problem there
[20:52] <humbletim> it's dependent on the language, not the implementation of it
[20:52] <Wes-> humbletim: well, if you want to stick to STRICTLY the features in the javascript language, good luck. It doesn't have I/O.
[20:53] <humbletim> you can run WSGI on IronPython, no?
[20:53] <Wes-> humbletim: beats me
[20:53] <ashb> humbletim: if you want to secure this, you can't make it generic.
[20:53] <humbletim> Wes-: i can write a WSGI app and toss it up for people to host. i cannot do that with a JSGI, ever, without strictly forcing them into a particular commonjs implementation. ?
[20:53] <ashb> since there is no generic way of doing the security
[20:54] <humbletim> i don't want to have to worry about module security as a JSGI developer tho, right?
[20:54] <Wes-> humbletim: I don't think you understand what you're implementing
[20:54] <humbletim> i mean the royal i
[20:55] <Wes-> if you want to secure sandboxes, write the secure sandbox standard
[20:55] <Wes-> get it voted on
[20:55] <Wes-> get people to implement it
[20:55] <humbletim> Wes-: i think you are 100% on that one. ;) i'm still experimenting, but really trying hard to align with specs as much as possible
[20:55] <Wes-> then any conforming implementation will work
[20:55] <Wes-> humbletim: disabling library access is not likely to be helpful
[20:55] <humbletim> Wes-: don't need to do that. just need to share my JSGI app with others.
[20:56] <Wes-> humbletim: you just said you didn't want your jsgi programs to be able to call require()
[20:56] <humbletim> oops, yeah, moved on past that point. ;)
[20:57] <humbletim> once i realized that still doesn't make for portable JSGI apps
[20:57] <humbletim> (just makes it a bit easier to home glue/sniff code)
[20:59] <humbletim> so on the horizon will CommonJS spec grow to include stock MD5/etc apis? if so, that glue code will disappear. if not, i'm stuck with it (or autonomous implementations for everything).
[21:00] <ashb> so the way i see, e.g. MD5, working is we have a central/common package repo
[21:00] <ashb> and everyone just uses that
[21:00] <Dantman> md5 would be part of a crypt library
[21:01] <ashb> like CPAN, or python's cheeseshop (i htink)
[21:02] <ashb> s/crpyt/digest/ to me, but the general idea is the same
[21:04] <humbletim> ok, so JSGI is CommonJS-GI, gotcha. i was thinking of it as an arbitrary gateway interface. by extension then, CommonJS is really to become a language, insomuch as Python's stdlib is part of that language. i can then imagine there will be roughly as many commonjs runtimes as there are javascript VMs.
[21:05] <ashb> yeah, JS ins the syntax, commonJS is the language
[21:05] <ashb> ins = is
[21:07] <humbletim> any discussions yet on a new filename extension since it sounds like CommonJS is to JS as XHTML is to XML?
[21:07] * ondras often uses .ssjs
[21:08] <ashb> i use .js for modules. i've juse .jsgi in a few places for the master .jsgi file
[21:17] <evilstreak> I like .js since it means editors don't need customising
[21:17] <evilstreak> to handle pulling in syntax and behaviour for extra extensions
[21:21] <Dantman> It'd be ages before gedit on ubuntu recognizes any commonjs extension alias for js
[21:21] <humbletim> evilstreak: i don't mind .js really, but until http://wiki.commonjs.org/wiki/Runtime_Services is flushed out, i'd like some way to differentiate CommonJS code from JS code
[21:22] <Dantman> .common.js? heh
[21:23] <humbletim> Dantman: sure, unless it's to be require()'d as a module some day. heh
[21:23] <ashb> humbletim: .but-tim-wants-something-not-dot-js
[21:23] <evilstreak> concise
[21:23] * Dantman supports .js .java.js and .jar
[21:23] <ashb> i thought so
[21:24] <Dantman> .cjs
[21:24] <ashb> again - .js since editors detect it
[21:35] <humbletim> i think i'll go with .jsx for stuff that needs to be preprocessed for each particular CommonJS implementation right now
[21:54] <ryah> preprocessed?
[21:56] <humbletim> ryah: yup, i know i'm sorta combining "./configure" with runtime, but want to develop high up sooner than packages will likely be available readily
[21:57] * ashb wonders what crazyness humbletim is concoting
[21:58] * humbletim is just remaining agnostic for as long as possible!
[21:58] <ashb> agnostic to any beyond commonJS base layer by the sounds of things
[21:58] <humbletim> for now, yup
[22:00] <humbletim> how else to avoid all sorts of redundant code across various levels of js/commonjs??
[22:00] <ashb> like what?
[22:01] <humbletim> like CommonJS on windows mobile, JSGI paradigm for server-pull (or browser-push, take your pick), etc.
[22:02] <ashb> you're just making work for you self
[22:02] <ashb> anything speced in commonjs will work on any commojs platform sooner or later
[22:02] <ashb> treat commonjs as the lowest common denominator
[22:03] <humbletim> i am making work for myself, but in the spirit of uber-connectedness-of-all-VMs
[22:03] <ashb> your choice
[22:06] * humbletim wears his crazy badge with honor (at least when experimenting)!
[22:11] <humbletim> ECMAScript-262 #16 (effectively) states an implementation can extend the syntax of the language by way of the Function object/constructor, so technically i'm not out-of-spec crazy yet. hehe
[22:13] <ashb> JohnResig: What does sizzle require in terms of API to use?
[22:14] <ashb> i.e. do i need to provide something like the DOM interface to make sizzle work in Juice (my JSGI app)
[22:21] <humbletim> ashb: for DOM and Browser-like stuff, i've had success decoupling env.js from the rhino and then chaining it with ajaxslt's dom stuff
[22:22] <ashb> humbletim: http://code.google.com/p/ajaxslt/ that ajaxslt?
[22:23] <humbletim> ashb: yeah but before getting distracted by other craziness i think i started to package it for redistro
[22:30] <humbletim> ashb: i'm still learning git, but give me a few and i'll put it up. it's pretty agnostic, too. seems to work with node, rhino (w/o java dependencies), smjs, and even firefox). none of the XMLHTTPRequest stuff, just window/DOM/document functional mocks.
[22:30] <ashb> cool
[22:31] <ashb> that would be awesome
[22:35] <humbletim> ashb: and don't forget crazy. so, two MIT-licensed projects, but google's is mod'd a bit. do i have to dual-license this or anything?
[22:35] <humbletim> (i mean they used different MIT language than env.js's)
[22:37] <ashb> if they claim its MIT, then treat it as MIT
[22:38] <ashb> just preserve the copyright lines
[22:38] <ashb> and stick a 'Licensed under MIT License: http://www.opensource.org/licenses/mit-license.php
[22:38] <ashb> or similar is what i'd do
[23:22] <ashb> i really whish all the narwhall guys would put a more explicit dep on rhino in their packages.json
[23:26] <tlrobinson> ashb: what?
[23:26] <tlrobinson> the engine shouldn't matter
[23:27] <ashb> tlrobinson: more aimed at random contributors than the core team
[23:27] <ashb> tlrobinson: that XML module email that just came thru is rhino only for instance
[23:27] <tlrobinson> ah
[23:27] <tlrobinson> haven't looked at it
[23:27] <ashb> just ranting cos if it was pure JS i could really do with it :)
[23:28] <tlrobinson> yeah, a js DOM implementation would be nice
[23:28] <ashb> exactly what i'm thinking :)
[23:28] <ashb> pure JS xml(html soup for bonus points) parser + Dom + sizzle = win
[23:31] <ashb> since right now my http-fetch module only supports binary or text
[23:32] <ashb> and sleep. &
[23:38] <humbletim> ashb: umm, you do realize you're making the case for portable, agnostic modules, right?
[23:40] <ashb> humbletim: yes. but using commonjs. not portable below that
[23:40] <ashb> i.e. i could care less aboutporting so js-shell for spdermonkey etc
[23:41] <humbletim> ashb: without such harnesses how would contributes even know they've created something implementation (ie: rhino) specific?
[23:41] <ashb> i'm all for pure js modules you can use on all commonjs patforms
[23:41] <ashb> humbletim: you dont use rhino specifics accidentally
[23:42] <humbletim> ashb: but if no other way exists you'll use rhino specifics every single time under pressure
[23:42] <ashb> this is the *point* of commonjs. to spec a common api for things that cant be done in pure js
[23:43] <ashb> and now really sleep.
[23:43] <ashb> have to be up in <7hrs
[23:43] <humbletim> ashb: you'll have a mixed blessing surprise tomorrow waiting for you in timjs-agnostics

 

 

Logs by date :