[14:21:17 CST(-0600)] <Bosmon> Welcome O BOTT!

[14:21:24 CST(-0600)] <yura>

[14:21:30 CST(-0600)] <EricDalquist> hello

[14:21:38 CST(-0600)] <Bosmon> We are just celebrating the creation of our first node.js "Fluid module"

[14:21:43 CST(-0600)] <Bosmon> Including the definition of what such a thing is....

[14:21:52 CST(-0600)] <yura> HAHA

[14:22:06 CST(-0600)] <Bosmon> Thanks so much for the BENNISON of this BOTT, O DAHLQUIST

[14:22:20 CST(-0600)] <EricDalquist> lol

[14:22:25 CST(-0600)] <EricDalquist> watching the logs ...

[14:22:31 CST(-0600)] <EricDalquist> to see if it actually creates the pages

[14:22:33 CST(-0600)] <Bosmon> I might have to paste back the material I just typed so that it gets logged

[14:22:35 CST(-0600)] <EricDalquist> as I claimed it would

[14:22:37 CST(-0600)] <Bosmon> Yes, that will be interesting

[14:22:46 CST(-0600)] <Bosmon> I guess it typically takes a few minutes for it to catch up?

[14:23:01 CST(-0600)] <EricDalquist> I believe it dumps out to the wiki every minute

[14:23:16 CST(-0600)] <avtar> hey Bosmon, EricDalquist

[14:23:18 CST(-0600)] <michelled> I see it on the wiki

[14:23:27 CST(-0600)] <Bosmon> Superb!

[14:23:31 CST(-0600)] <avtar> i saw my name mentioned in #fluid-work

[14:23:38 CST(-0600)] <Bosmon> Hi avtar

[14:23:47 CST(-0600)] <EricDalquist> yay, its working

[14:23:48 CST(-0600)] <EricDalquist> ok

[14:23:49 CST(-0600)] <Bosmon> Yes, just wanted you in the loop re the logging of this channel

[14:23:59 CST(-0600)] <EricDalquist> back to uPortal upgrading at UW

[14:24:01 CST(-0600)] <Bosmon> Eric has very kindly extended the AEGIS of his BOTT

[14:24:07 CST(-0600)] <Bosmon> Thanks, EricDalquist

[14:24:19 CST(-0600)] <avtar> cool, thanks Bosmon

[14:24:22 CST(-0600)] <Bosmon> Ok, somewhat to the annoyance of people in this channel, I will now reecho all my comments of a couple of minutes ago

[14:24:27 CST(-0600)] <Bosmon> So that they get logged properly

[14:24:41 CST(-0600)] <EricDalquist> fyi for anyone interested the source is here: https://source.jasig.org/sandbox/ConfluenceIrcLogger/trunk/

[14:25:05 CST(-0600)] <Bosmon> For anyone interested in the issues, yura and I are currently debunking some GPII code he has written

[14:25:11 CST(-0600)] <Bosmon> http://pastebin.com/g6BSVejY

[14:25:19 CST(-0600)] <Bosmon> This is our first attempt to create a "node-compliant" "Fluid module"

[14:25:24 CST(-0600)] <Bosmon> Right now it fails nastily with a fairly incomprehensible framework error message, resulting from a component unexpectedly being null when IoC is trying to resolve it

[14:25:30 CST(-0600)] <Bosmon> We are considering that the "fluid.require" we invented last night is not actually correct for a "node compliant" "Fluid module"

[14:25:40 CST(-0600)] <Bosmon> For example, a "Fluid module" typically has a side-effect by assigning itself into the correct place in the (single) Fluid namespace

[14:25:46 CST(-0600)] <Bosmon> Or assigning whatever components it defines there

[14:25:52 CST(-0600)] <Bosmon> So it is unnecessary, and dangerous, in general, to expose a model where the end-user is expected to further tinker with the Fluid namespace on their own recognizance....

[14:26:03 CST(-0600)] <Bosmon> The way out of this seems to be to create a dedicated method called "fluid.load"

[14:26:11 CST(-0600)] <Bosmon> Which internally dispatches to "require", of course, but is more self-contained in that it

[14:26:17 CST(-0600)] <Bosmon> i) makes no return value

[14:26:22 CST(-0600)] <Bosmon> ii) provides no affordance to randomly assign things around the Fluid namespace

[14:26:28 CST(-0600)] <Bosmon> It simply calls require, which has the effect of loading and executing the "Fluid module" (at most once) which then in itself automatically puts its materials into the Fluid namespace

[14:26:35 CST(-0600)] <Bosmon> And then returns

[14:26:41 CST(-0600)] <Bosmon> We can keep fluid.require for emergencies, but I doubt it will ever be used

[14:26:46 CST(-0600)] <Bosmon> But there is a very small chance you might want a free function in a 3rd-party library to be visible to fluid

[14:26:56 CST(-0600)] <Bosmon> [13:17] <yura> OMG IT WORKS

[14:26:56 CST(-0600)] <Bosmon> [13:19] <yura> so this implemntation of dataSource works

[14:26:56 CST(-0600)] <Bosmon> [13:19] <yura> http://pastebin.com/GKHgQYu9

[14:26:56 CST(-0600)] <Bosmon> [13:20] <yura> and this is a snapshot of express app http://pastebin.com/wpYLd5Q7

[14:29:03 CST(-0600)] <Bosmon> yura is now implementing fluid.load

[14:29:19 CST(-0600)] <Bosmon> Currently his loader code still looks like this:

[14:29:19 CST(-0600)] <yura> so Bosmon, fluid load will except a path to fluid module ?

[14:29:21 CST(-0600)] <Bosmon> var express = require("express"),

[14:29:21 CST(-0600)] <Bosmon> fluid = require("infusion"),

[14:29:21 CST(-0600)] <Bosmon> gpii = fluid.registerNamespace("gpii");

[14:29:21 CST(-0600)] <Bosmon> fluid.require("../../../../../dataSource.js");

[14:29:32 CST(-0600)] <Bosmon> yura - that's right, signature of fluid.load is identical to "require"

[14:29:41 CST(-0600)] <Bosmon> it's just that it uses fluid's own require

[14:29:49 CST(-0600)] <Bosmon> hmmmm...

[14:29:52 CST(-0600)] <yura> right

[14:30:09 CST(-0600)] <Bosmon> Well

[14:30:14 CST(-0600)] <Bosmon> Actually that's irrelevant too, isn't it!

[14:30:18 CST(-0600)] <Bosmon> We can just use require itself

[14:30:28 CST(-0600)] <Bosmon> There is no longer anything special about the action of the module loader

[14:30:40 CST(-0600)] <Bosmon> Since the module itself gets access to the fluid object via require

[14:30:57 CST(-0600)] <yura> yes

[14:31:12 CST(-0600)] <Bosmon> It is guaranteed by the module spec, isn't it, that every call to require("x") returns the same object reference, for the same x?

[14:31:55 CST(-0600)] <yura> yes Bosmon, unless you explicitly want to reload it

[14:32:07 CST(-0600)] <Bosmon> Can you find a link to that bit of the spec?

[14:32:14 CST(-0600)] <Bosmon> I am just reading CommonJS wiki and not finding it yet

[14:33:40 CST(-0600)] <yura> http://nodejs.org/docs/latest/api/modules.html#caching

[14:34:20 CST(-0600)] <yura> Bosmon:

[14:34:25 CST(-0600)] <Bosmon> Ok

[14:34:34 CST(-0600)] <Bosmon> It's worthwhile knowing that the caching is done based on the module filename

[14:34:46 CST(-0600)] <Bosmon> We need to make sure to warn people that fluid must be loaded from the same FS path each time

[14:38:29 CST(-0600)] <colinclark> Bosmon, yura: I can't tell you how stoked I am to catch up on the logs in here and see the crazy things you are cooking up

[14:39:32 CST(-0600)] <Bosmon> http://nodejs.org/docs/latest/api/modules.html#all_Together...

[14:39:51 CST(-0600)] <Bosmon> Based on this guide, I think we need to make a standard that fluid is always loaded from the module path

[14:40:16 CST(-0600)] <Bosmon> That is, that it is loaded with exactly this statement: var fluid = require("infusion")

[14:48:48 CST(-0600)] <Bosmon> New version of GPII code at http://pastebin.com/JwSBTuHm

[14:48:57 CST(-0600)] <Bosmon> Just discussing the need to process SIGTERM manually

[14:50:25 CST(-0600)] <Bosmon> Looking pretty awesome

[14:50:42 CST(-0600)] <Bosmon> Nice use of a typeTag to distinguish production and development environments

[14:50:52 CST(-0600)] <Bosmon> I guess you are still in the middle of getting rid of "fluid.require" calls : P

[14:51:12 CST(-0600)] <Bosmon> Some material I think belongs in the fluid namespace

[14:51:16 CST(-0600)] <Bosmon> For example, the dataSource

[14:51:27 CST(-0600)] <Bosmon> The gpii namespace is right for the preferences server

[14:53:19 CST(-0600)] <yura> so what would dataSource be namespaced to ?

[14:53:29 CST(-0600)] <colinclark> this is one of those times when a collaborative editor would be kind of nice

[14:53:47 CST(-0600)] <colinclark> Bosmon: Are we thinking of reviving the Kettle brand?

[14:53:54 CST(-0600)] <Bosmon> colinclark - I was thinking so, yes

[14:53:58 CST(-0600)] <colinclark> As was I

[14:54:05 CST(-0600)] <colinclark> I guess data sources are cross-location, though?

[14:54:15 CST(-0600)] <Bosmon> This code is the beginnings of kettle "from the ground up"

[14:54:16 CST(-0600)] <colinclark> i.e. They're equally a browser technology?

[14:54:19 CST(-0600)] <colinclark> yay

[14:54:33 CST(-0600)] <Bosmon> colinclark - the "dataSource API" itself is cross-location, yes

[14:54:44 CST(-0600)] <Bosmon> BUt the particular concrete instances of them here will be kettle/node specific

[14:54:47 CST(-0600)] <colinclark> right

[14:55:02 CST(-0600)] <Bosmon> Given we are not Object-Oriented types, we don't actually really have anywhere to put the interface : P

[14:55:05 CST(-0600)] <colinclark> Because they have to bind either to .ajax or to Node's HTTPClient, right?

[14:55:11 CST(-0600)] <Bosmon> Although it's possible we might give it a "grade name" someday

[14:55:21 CST(-0600)] <Bosmon> And if we did, that grade name would go in the top-level fluid namespace

[14:55:29 CST(-0600)] <Bosmon> colinclark - right

[14:55:37 CST(-0600)] <Bosmon> Or the node fs module

[14:56:14 CST(-0600)] <Bosmon> Let me look at what I did with vestigial "kettle node"...

[14:56:34 CST(-0600)] <Bosmon> Oh, interesting

[14:56:38 CST(-0600)] <Bosmon> I made kettle top-level

[14:56:58 CST(-0600)] <colinclark> top-level in the fluid namespace?

[14:57:06 CST(-0600)] <Bosmon> Wait, I got confused

[14:57:13 CST(-0600)] <Bosmon> That is just the old "primordial boot loader"...

[14:57:16 CST(-0600)] <Bosmon> Yes, it is like this

[14:57:17 CST(-0600)] <Bosmon> fluid.kettle.node.loadApp = function(config, app, appEntry, dir, cont) {

[14:57:25 CST(-0600)] <Bosmon> Do we like this model for namespacing?

[14:57:38 CST(-0600)] <Bosmon> So in this case we would make fluid.kettle.node.dataSource ?

[14:57:39 CST(-0600)] <Bosmon> etc.

[14:57:51 CST(-0600)] <Bosmon> or rather HTTPDataSource and FSDataSource etc.

[14:58:35 CST(-0600)] <Bosmon> Or make a URLDataSource as an abstraction on top of both of them, that could take both http:// and file:// URLs as options

[14:58:45 CST(-0600)] <Bosmon> It's all declarative, so shouldn't make a huge difference

[15:00:19 CST(-0600)] <Bosmon> Well

[15:00:29 CST(-0600)] <Bosmon> I guess it is good to no longer be promoting our own module system

[15:00:36 CST(-0600)] <Bosmon> Another part of bloody Kettle we no longer need to implement

[15:00:37 CST(-0600)] <colinclark>

[15:00:49 CST(-0600)] <colinclark> So, sorry Bosmon...

[15:01:00 CST(-0600)] <colinclark> were you asking for suggestions?

[15:01:13 CST(-0600)] <colinclark> i maybe didn't fully get your two proposals (if you were)

[15:01:16 CST(-0600)] <Bosmon> suggestions and/or comments yes

[15:01:21 CST(-0600)] <Bosmon> I think there was just one proposal

[15:01:25 CST(-0600)] <Bosmon> http://issues.fluidproject.org/browse/KETTLE-7 anyone??! : P

[15:01:35 CST(-0600)] <Bosmon> I guess we can close this JIRA from Nov 09

[15:01:38 CST(-0600)] <colinclark> :0

[15:01:39 CST(-0600)] <colinclark>

[15:01:50 CST(-0600)] <colinclark> THE KETTLE ICON!

[15:02:00 CST(-0600)] <Bosmon> Actually we still have SOME work to do here

[15:02:03 CST(-0600)] <colinclark> I wonder if jameswy will let me join the designers

[15:02:08 CST(-0600)] <colinclark> please?

[15:02:31 CST(-0600)] <Bosmon> You will need to type as fast as him, in an Arthurian Jousting Tournament

[15:02:35 CST(-0600)] <colinclark> What was the one proposal again, Bosmon?

[15:02:43 CST(-0600)] <colinclark> He's 20 wpm ahead of me, it would be suicide

[15:02:50 CST(-0600)] <Bosmon> Although npm explains how modules load, we still need some system for connecting to the routing engine

[15:02:59 CST(-0600)] <Bosmon> So we can leave this JIRA open a little longer : P

[15:03:09 CST(-0600)] <Bosmon> Anyway, that will become clear once JURA develops a few GPII components

[15:03:17 CST(-0600)] <colinclark> so awesome

[15:03:24 CST(-0600)] <Bosmon> I was proposing this multi-level namespace

[15:03:29 CST(-0600)] <Bosmon> Based on fluid.kettle.node.*

[15:03:36 CST(-0600)] <colinclark> I think it's sensible...

[15:03:40 CST(-0600)] <Bosmon> Do we think it is too verbose, or do we like it?

[15:03:44 CST(-0600)] <colinclark> but it does start to get a bit deeply nested

[15:03:46 CST(-0600)] <colinclark> i.e. verbose

[15:03:54 CST(-0600)] <colinclark> I had this same feeling with this kind of namespacing in Flocking

[15:03:59 CST(-0600)] <colinclark> where at some point I started to feel a touch silly

[15:04:08 CST(-0600)] <Bosmon> I found myself creating local aliases when actually using things

[15:04:14 CST(-0600)] <Bosmon> Which I think could be a helpful approach

[15:04:14 CST(-0600)] <colinclark> yeah, which is not really a big deal

[15:04:16 CST(-0600)] <Bosmon> For example:

[15:04:24 CST(-0600)] <colinclark> Python programmers do it all the time

[15:04:35 CST(-0600)] <Bosmon> var geom = org.weblogo.geom;

[15:04:41 CST(-0600)] <Bosmon> Although of course one can't do this in IoC configuration

[15:04:47 CST(-0600)] <colinclark> indeed

[15:04:49 CST(-0600)] <Bosmon> Which is where we imagine a lot of the references may appear

[15:04:59 CST(-0600)] <Bosmon> Although on the other hand, full namespacing in IoC configuration could be quite valuable

[15:05:06 CST(-0600)] <Bosmon> Following on from Gottfriedism, etc.

[15:05:24 CST(-0600)] <colinclark> Gottfried would indeed approve

[15:05:28 CST(-0600)] <colinclark> flat and specific

[15:05:32 CST(-0600)] <colinclark> at the cost of verbosity

[15:05:48 CST(-0600)] <colinclark> I was trying to make this point to Gregg the other day

[15:06:00 CST(-0600)] <colinclark> that, in practice, "foo.bar.baz" was the same thing as

[15:06:10 CST(-0600)] <Bosmon> If we could separate out the requirements of a routing engine into a declarative form, there's no reason why we couldn't support express permanently as an option for kettle

[15:06:15 CST(-0600)]

Unknown macro: { foo}

[15:06:17 CST(-0600)] <Bosmon> Whilst continuing to code against it with Fluid components

[15:06:45 CST(-0600)] <colinclark> That would be really excellent if it's possible

[15:06:55 CST(-0600)] <colinclark> I guess you and yura will spend some time with it actually doing some coding to see?

[15:06:57 CST(-0600)] <Bosmon> "I can't see any reason why it couldn't work" : P

[15:06:58 CST(-0600)] <Bosmon> Yes

[15:07:07 CST(-0600)] <Bosmon> This can all be coded "emergently" .....

[15:07:15 CST(-0600)] <colinclark> Probably best to know the Express model well

[15:07:20 CST(-0600)] <colinclark> before adding our declarative twist to it

[15:07:26 CST(-0600)] <Bosmon> Yes

[15:07:31 CST(-0600)] <colinclark> I remember learning CherryPy for real

[15:07:38 CST(-0600)] <Bosmon> Well, it's surely all based on STRINGS and such

[15:07:40 CST(-0600)] <colinclark> after seeing it sort of kaleidoscopically reflected through Kettle

[15:07:42 CST(-0600)] <Bosmon> How undeclarative could it be : P

[15:07:43 CST(-0600)] <colinclark>

[15:07:50 CST(-0600)] <Bosmon> Cool

[15:08:07 CST(-0600)] <Bosmon> CherryPy in Decapod?

[15:11:07 CST(-0600)] <Bosmon> Well, it looks that carried to any extent, Express will commit us to the "rat's nest of function pointers" model... but their string syntax for describing routes looks like it could be lifted out

[15:11:31 CST(-0600)] <Bosmon> It looks like the standard signature for anything in express looks like ", function(req, res, next)"

[15:12:00 CST(-0600)] <Bosmon> Very Servletlike!

[15:12:28 CST(-0600)] <colinclark> A model you are very familiar with

[15:12:49 CST(-0600)] <Bosmon> Everyone loves having the request and response exposed in every method!

[15:12:53 CST(-0600)] <Bosmon> It's so HACKABLE!

[15:13:44 CST(-0600)] <Bosmon> Should be pretty easy to integrate the renderer into express' "view rendering engine"....

[15:14:00 CST(-0600)] <Bosmon> " To alter this behaviour app.register() can be used to map engines to file extensions, so that for example “foo.html” can be rendered by ejs."

[15:14:30 CST(-0600)] <Bosmon> This is going to be fun...

[15:15:02 CST(-0600)] <Bosmon> Pretty soon I imagine we will need to get to the "a request is a component" model, inspired by the CSpace Tabs system : P

[15:18:46 CST(-0600)] <Bosmon> Perhaps we can persuade express to represent the "request component" as a "partial"....

[15:18:57 CST(-0600)] <Bosmon> Which actually goes into the "response"

[15:19:59 CST(-0600)] <Bosmon> http://expressjs.com/guide.html#res.partial()

[15:35:53 CST(-0600)] <yura> https://github.com/yzen/PreferencesServer

[15:38:17 CST(-0600)] <Bosmon> Looks great

[15:38:27 CST(-0600)] <Bosmon> Do we have a dedicated GPII component in JIRA yet?

[15:38:38 CST(-0600)] <Bosmon> We should start imposing JIRA number commit discipline on this project too

[15:39:11 CST(-0600)] <Bosmon> It's odd that you committed all the source for express

[15:39:17 CST(-0600)] <Bosmon> Shouldn't people get that themselves out of npm?

[15:40:51 CST(-0600)] <Bosmon> And also all the code for infusion too!

Browser not supported