[5:58]<giacecco> Hi all. Easy question: what's CommonJS' answer to the need of having an XML parser? [6:01]<giacecco> ... and possibly one capable of running the same code on server and clients, btw [6:01]<giacecco> identically [6:03]<ondras> xml parsing can be done automatically via e4x, if your embedding is based on spidermonkey [6:03]<ondras> (and possibly rhino?) [6:03]<giacecco> ondras: yep, but e4x is not available on Safari, Chrome and IE [6:03]<giacecco> I need to reuse the code I write for the parser [6:04]<ondras> other embedings need xml parsers - I have one for v8cgi; http://code.google.com/p/v8cgi/source/browse/trunk/lib/dom.js [6:04]<giacecco> v8cgi is my current solution but I am not completely happy [6:04]<ondras> can we improve your situations by enhancing/fixing stuff in v8cgi? :) [6:05]<ondras> *situation [6:08]<giacecco> ondras: oh yes :-) but I did not want to push you [6:08]<giacecco> what's the roadmap there? [6:09]<ondras> hm, hard to tell [6:09]<ondras> from my point of view, everything now awaits final Binary standard [6:10]<ondras> after that, some modules can be refactored (sockets) [6:11]<ondras> and some new can be added (zlib, memcached) [6:11]<ondras> no further plans :) [6:12]<giacecco> what about documentation? [6:12]<ondras> yeah, I guess people would appreciate that [6:12]<ondras> unfortunately, I really suck at writing docs :/ [6:15]<ondras> but let me know what do you want [6:15]<ondras> or better, post that as a feature reqest at v8cgi discussion group [6:15]<ondras> *request [6:22]<giacecco> ok thank you ondras [6:22]<giacecco> one last question [6:22]<giacecco> what would you say are the pros of your implementation in respect to past attempts? [6:23]<ondras> what past attempts, specifically? [6:25]<giacecco> this for example http://xmljs.sourceforge.net [6:26]<giacecco> and the last question: since you look like you like e4x, do you know why nobody wrote a pure Javascript implementation? [6:28]<ondras> e4x cannot be, as far as i know, implemented atop an existing js interpreter [6:28]<ondras> as it requires syntax support [6:28]<ondras> (e4x is not a valid ecmascript source code) [6:28]<ondras> as for xmljs - I know that all browsers offer native xml parsing mechanisms [6:28]<ondras> so I was not looking for these [6:29]<ondras> instead, I needed something compatible with CommonJS modules [6:29]<ondras> I believe there was no such thing when I wrote my dom.js [6:29]<giacecco> clear [6:29]<giacecco> of course the syntax thing makes it impossible in pure JS [6:30]<ondras> I am "kind of" fan of e4x [6:30]<giacecco> well thank you then, I guess I'll stick to dom.js [6:30]<ondras> it is nice [6:30]<ondras> but there are already existing apis [6:30]<ondras> such as DOMParser [6:30]<ondras> implemented in many browsers [6:31]<giacecco> yeah but if you want to port your code across browser and server you need something like your dom.js [6:32]<giacecco> with HTML5 clients will become more and more clever, and there will be lots of data processing on both sides [6:32]<giacecco> one can't write the same stuff twice because the parsers are different [6:32]<ondras> that is very true [6:32]<ondras> but are not all xml parsers expected to give same results? [6:33]<giacecco> yes, but they are not programmed in the same way [6:33]<giacecco> imagine that, like in my case, the browser is some kind of a little server too [6:33]<giacecco> and the server has those same 'little server' functionality [6:33]<giacecco> I don't want to write the code twice [6:34]<giacecco> or more because there are subtle differences between IE's parser and Firefox' parser and Chrome's parser... [6:34]<ondras> hmhm [6:34]<ondras> honestly, i never thought about using dom.js on client :) [6:35]<giacecco> oops [6:35]<giacecco> you mean it may not be portable? [6:36]<ondras> no [6:36]<ondras> this usage just never came to my mind [6:37]<ondras> however, when you talk about unportable code... there are setters and getters there :/ [6:37]<ondras> I am not sure about their browser support.. [6:38]<giacecco> :-( [6:39]<giacecco> well, you understand where I come from [6:39]<ondras> yeah :/ [6:39]<giacecco> I believe CommonJS needs an XML parser written in pure JS that works seamlessly across web browsers, too [6:40]<giacecco> a JQuery of XML [6:40]<giacecco> no, actually JQuery does not work on CommonJS :-/ [6:46]<giacecco> what do you think, are you interested in making dom.js that parser? [6:53]<ondras> let me look at it [6:55]<ondras> avoiding those getters/setters means more messy code and worse performance [6:55]<ondras> on the other hand, it would be good to know what is the current support for __defineGetter__ and __defineSetter__ [6:55]<ondras> perhaps IE understands this in some way? [6:56]<giacecco> no idea [6:56]<giacecco> what I know is that that would make your library key in the next couple of years [6:56]<giacecco> and relevant well outside v8cgi [6:56]<giacecco> you may actually propose it as a CommonJS standard [6:57]<ondras> my library only implements several existing apis [6:57]<ondras> so there already is a standard [6:57]<giacecco> y sorry [6:57]<ondras> and because it is a module, it is very relevant outside v8cgi [6:57]<ondras> actually, it has basically no relation to v8cgi [6:57]<ondras> (they only share the same coder) [6:57]<giacecco> true, indeed I am not using it with v8cgi but with RingoJS [6:58]<giacecco> my stack is AppengineJS/RingoJS/Java Google App Engine [7:04]<giacecco> I have to go, thank you for your help and contribution [7:05]<giacecco> do you have a "Donate" button somewhere? [7:05]<ondras> http://code.google.com/p/v8cgi/ [7:05]<ondras> here :) [7:08]<giacecco> cool have a drink on me [7:08]<giacecco> goodbye [17:49]<kriskowal> hey, ondras. just wanted to let you know that i, at least, am not pushing for "finalization" of particular standards any more. i think binary/b and binary/f are both suitable for implementation at this point. [19:14]<ondras> kriskowal: okay, thanks [19:14]<kriskowal> np