fluid-tech IRC Logs-2012-09-20

[13:49:10 CDT(-0500)] <Bosmon> Bouncy Bouncy

[13:49:17 CDT(-0500)] <yura1> Bosmon: hi

[13:50:11 CDT(-0500)] <yura> so i guess my higher level question is why do we want to use browser tests in general ?

[13:50:51 CDT(-0500)] <Bosmon> yura - because they are easier to run and to debug

[13:51:25 CDT(-0500)] <Bosmon> And, perhaps perversely, because they provide greater guarantees that we have successfully managed to mock out the environment : P

[13:51:51 CDT(-0500)] <Bosmon> It seems silly not to use a nice HTML-based interface for selecting and evaluating test cases, if we have one

[13:52:01 CDT(-0500)] <Bosmon> Rather than some 1980s style text transcript + node-inspector....

[13:52:16 CDT(-0500)] <Bosmon> So my view is that we should reserve node-based tests only for emergencies, such as large-scale integration tests

[13:52:19 CDT(-0500)] <Bosmon> What do you think, colinclark?

[13:53:29 CDT(-0500)] <colinclark> catching up

[13:53:44 CDT(-0500)] <colinclark> Well, since Boulder

[13:53:46 CDT(-0500)] <colinclark> as you know

[13:53:57 CDT(-0500)] <colinclark> I have been a strong advocate of browser-based tests

[13:54:03 CDT(-0500)] <colinclark> They are really quite convenient

[13:54:11 CDT(-0500)] <colinclark> With QUnit's new multiple test support, they're even more so

[13:54:28 CDT(-0500)] <colinclark> I guess I can see a world where the cost of mocking the environment could get very high

[13:54:37 CDT(-0500)] <colinclark> but I guess I'd like to see it first

[13:54:45 CDT(-0500)] <colinclark> yura: Do you think you have a very expensive case here?

[13:55:14 CDT(-0500)] <yura> colinclark: well it's a common case i guess, where something depends on a genuine node module

[13:56:25 CDT(-0500)] <yura> we are in luck however where such modules work both on the server and client side

[13:56:47 CDT(-0500)] <yura> since we can use it as a client side stub for itself

[13:57:21 CDT(-0500)] <yura> but then something to think about is what should the mechanism of loading such modules in tests

[13:57:45 CDT(-0500)] <yura> so Bosmon mentioned browserify yesterday which can potentially help with that

[13:57:50 CDT(-0500)] <yura> but not ideal

[13:58:03 CDT(-0500)] <yura> another approach would be updating our require stub

[13:58:08 CDT(-0500)] <yura> to load things other than infusion

[13:58:18 CDT(-0500)] <yura> such as this when node module

[13:58:39 CDT(-0500)] <yura> but then the require stub clearly needs a way of looking this modules up

[13:59:03 CDT(-0500)] <Bosmon> yura - right

[13:59:15 CDT(-0500)] <Bosmon> So, we have a few possibilities

[13:59:18 CDT(-0500)] <yura> hence my yesterday question about whether we should lookup things in a similar way node does even with out require stub

[13:59:25 CDT(-0500)] <Bosmon> We could simply write a little JSON lookup file, for example

[13:59:39 CDT(-0500)] <Bosmon> Yes, the issue is that we are constrained in the browser, in that we can't perform "filesystem searches"

[14:00:14 CDT(-0500)] <yura> Bosmon: why not ?

[14:00:22 CDT(-0500)] <Bosmon> Well, the browser can't do that

[14:00:31 CDT(-0500)] <Bosmon> There's no primitive for that in HTML/JS

[14:00:42 CDT(-0500)] <yura> well i can try loading scripts left and right until i get what i want

[14:00:43 CDT(-0500)] <yura> or not

[14:00:49 CDT(-0500)] <Bosmon> Yes, but that's a little silly

[14:01:09 CDT(-0500)] <yura> haha isnt what node module resolution is

[14:01:20 CDT(-0500)] <Bosmon> no... module resolution can actually itemise the contents of a directory

[14:01:23 CDT(-0500)] <Bosmon> The browser can't

[14:01:43 CDT(-0500)] <Bosmon> So..... it will need to be told somehow, exactly what the path of each module is

[14:01:46 CDT(-0500)] <yura> Bosmon: that's correct

[14:01:49 CDT(-0500)] <Bosmon> Which isn't terribly onerous, for a test case

[14:01:55 CDT(-0500)] <Bosmon> We do it anyway, every time we write an HTML page

[14:02:12 CDT(-0500)] <Bosmon> Just in this case we need to do it slightly differently to make the return value from the "require" statement correct

[14:02:54 CDT(-0500)] <yura> Bosmon: ok ill try something out

[14:03:01 CDT(-0500)] <Bosmon> It seems to me that things like "browserify" are unnecessarily complex.... at least for the purpose of writing test cases

[14:03:21 CDT(-0500)] <Bosmon> I mean, they are incredibly ambitious, in that they will parse your ENTIRE source tree, looking for potential secret "require" statements

[14:04:50 CDT(-0500)] <colinclark> Can you remind me what browserify offers?

[14:05:13 CDT(-0500)] <Bosmon> browserify is a kind of "build-time step"

[14:05:28 CDT(-0500)] <Bosmon> It will take a body of node-aware code, complete with all of its require statements

[14:05:32 CDT(-0500)] <Bosmon> And then spit out a kind of "package"

[14:05:51 CDT(-0500)] <Bosmon> A parcel of HTML + JS which has all of the require statements and the things they refer to built together

[14:06:41 CDT(-0500)] <Bosmon> https://github.com/substack/node-browserify

[14:06:50 CDT(-0500)] <Bosmon> It is invoked like this:

[14:06:51 CDT(-0500)] <Bosmon> $ browserify entry.js -o bundle.js

[14:06:58 CDT(-0500)] <Bosmon> So this creates an output "bundle.js"

[14:08:15 CDT(-0500)] <Bosmon> I'm not sure what they look like, but they will probably look quite nasty

[14:08:27 CDT(-0500)] <Bosmon> So also would most likely be quite obstructive from the debugging angle

[14:08:40 CDT(-0500)] <Bosmon> It would at least, be comparable to debugging infusion from CSpaceInfusion.js etc

[14:08:55 CDT(-0500)] <yura> hahaha

[14:09:18 CDT(-0500)] <colinclark> why do you think it would be problematic for debugging?

[14:09:19 CDT(-0500)] <Bosmon> Which perhaps the likes of yura would manage, but for most normal people would be offputting : P

[14:09:43 CDT(-0500)] <Bosmon> Because all info about filenames and line numbers would most likely be gone... and there would probably be some extra peculiar "packaging material" in the file too

[14:10:31 CDT(-0500)] <Bosmon> The upside of browserify is that it contains support for a lot of the built-in node libraries

[14:11:52 CDT(-0500)] <Bosmon> I guess to me the downsides are i) the explicit build step, ii) the obstruction to debugging

[14:13:30 CDT(-0500)] <yura> Bosmon: so i guess this require from predefined json is inline with the work envisioned for dependancy management

[14:14:12 CDT(-0500)] <Bosmon> yura - it could be, yes

[14:14:24 CDT(-0500)] <Bosmon> For a start, we are planning to abolish the use of "require" for "GPII-aware code"

[14:14:33 CDT(-0500)] <Bosmon> But of course we could never abolish its use for standard node modules

[14:15:19 CDT(-0500)] <Bosmon> But we imagine that the runtime GPII system will indeed maintain such a JSON database of dependencies it has found, together with their locations

[14:15:45 CDT(-0500)] <Bosmon> The fusion between this requirement for testing, and the future loading architecture is a bit distant, but possible

[14:18:17 CDT(-0500)] <Bosmon> So yes... it is "in line" in that they both proceed from a little JSON database... but they will most likely be generated by different processes

[14:18:31 CDT(-0500)] <Bosmon> Our approach in "future GPII" will simply be to "load everything which can possibly be found"

[14:18:35 CDT(-0500)] <Bosmon> At least in the first instance

[14:18:53 CDT(-0500)] <Bosmon> But obviously this can't replicate the behaviour of old-style require() of which the crucial element is the RETURN VALUE

[14:19:33 CDT(-0500)] <Bosmon> So I think to that extent, the work for "require for testing" and "future GPII loading" are somewhat distinct

[15:12:04 CDT(-0500)] <Bosmon> colinclark, yura - ready to meet soon, if you are

[15:12:18 CDT(-0500)] <colinclark> i'm ready in two minutes

[15:14:35 CDT(-0500)] <colinclark> anastasiac: I'm just finally getting time to read closely the stuff you forwarded along from Maria

[15:14:57 CDT(-0500)] <anastasiac> thanks, colinclark

[15:15:05 CDT(-0500)] <colinclark> I'm quite happy for you to write 3.1.1 if you feel equipped to do so

[15:15:20 CDT(-0500)] <colinclark> I'm just trying to think what the current environment and limitations is like

[15:15:24 CDT(-0500)] <colinclark> and the web, I guess is different

[15:15:47 CDT(-0500)] <colinclark> We can talk about robust support for AT APIs in Firefox and, to varying degrees, in other browsers

[15:16:05 CDT(-0500)] <colinclark> And then the challenge of encouraging adoption

[15:16:08 CDT(-0500)] <colinclark> of those APIs

[15:16:12 CDT(-0500)] <colinclark> first by toolkit developers

[15:16:18 CDT(-0500)] <colinclark> can mention good support in Dojo and jQuery UI as examples

[15:16:34 CDT(-0500)] <colinclark> but also the need for application developers to embrace ARIA more widely

[15:16:56 CDT(-0500)] <colinclark> Also, I guess the other key thing is that we want to emphasize the Web as a platform-an operating system-in itself

[15:17:14 CDT(-0500)] <colinclark> but with as-yet early implementations of prominent assistive technologies

[15:17:28 CDT(-0500)] <colinclark> web anywhere being the primary example of a web-based AT, and it's mentioned below

[15:17:40 CDT(-0500)] <colinclark> I'm trying to think if there's anything else noteworthy

[15:20:03 CDT(-0500)] <colinclark> I can't think of anything specific to add to section 3.3, anastasiac

[15:20:36 CDT(-0500)] <anastasiac> ok, colinclark, thanks for the input. I'll draft something and run it by you, if that's ok with you

[15:20:45 CDT(-0500)] <colinclark> sure thing

[15:20:49 CDT(-0500)] <colinclark> thanks so much

[15:20:54 CDT(-0500)] <anastasiac> np

[15:25:17 CDT(-0500)] <colinclark> Bosmon: has yura reappeared, or should we start without him?

[15:26:32 CDT(-0500)] <Bosmon> colinclark - you can't see him? ;P

[15:26:40 CDT(-0500)] <colinclark> I'm at home today

[15:27:39 CDT(-0500)] <Bosmon> aha

[15:27:45 CDT(-0500)] <Bosmon> You could use your TELESCUPE