/
fluid-work IRC Logs-2008-07-31

fluid-work IRC Logs-2008-07-31

Owned by Fluid IRC Log Bot
Last updated: Jul 31, 2008Version comment

[04:32:52 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[08:03:27 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has joined #fluid-work
[08:46:39 EDT(-0400)] * athena7 (n=athena7@adsl-75-58-125-195.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[08:52:44 EDT(-0400)] * Justin_o_ (n=Justin@142.150.154.235) has joined #fluid-work
[09:00:33 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[09:11:41 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[09:34:17 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:38:02 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:15:41 EDT(-0400)] * anastasiac (n=stasia@142.150.154.160) has joined #fluid-work
[11:46:12 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[11:55:43 EDT(-0400)] * apetro_mac (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[12:01:56 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-27.LIPS.Berkeley.EDU) has joined #fluid-work
[12:07:38 EDT(-0400)] <jacobfarber> ecochran
[12:07:55 EDT(-0400)] <ecochran> jacobfarber: g'day
[12:08:00 EDT(-0400)] <jacobfarber> ecochran: did you want to set up a time to discuss the templates?
[12:08:04 EDT(-0400)] <ecochran> yes
[12:08:04 EDT(-0400)] <jacobfarber> sorry bout that
[12:08:10 EDT(-0400)] <ecochran> bout what?
[12:08:20 EDT(-0400)] <jacobfarber> accidentally typing your name twice
[12:08:30 EDT(-0400)] <ecochran> didn't notice
[12:08:49 EDT(-0400)] <ecochran> tomorrow is open for some preliminary planning
[12:09:03 EDT(-0400)] <jacobfarber> do you have a specific time?
[12:09:12 EDT(-0400)] <ecochran> anytime
[12:09:20 EDT(-0400)] <ecochran> 10am, my time?
[12:09:24 EDT(-0400)] <ecochran> 1pm, you
[12:09:28 EDT(-0400)] <jacobfarber> sounds great
[12:09:43 EDT(-0400)] <ecochran> OK, done
[12:09:50 EDT(-0400)] <ecochran> do you feel you have a good sense of what Colin has in mind?
[12:09:56 EDT(-0400)] <ecochran> I think that I do...
[12:10:10 EDT(-0400)] <jacobfarber> let me get him in here....
[12:10:27 EDT(-0400)] <colinclark> I'm here.
[12:10:42 EDT(-0400)] <jacobfarber> colinclark: you think we can discuss template ideas?
[12:10:52 EDT(-0400)] <colinclark> Yes, of course.
[12:11:08 EDT(-0400)] <jacobfarber> or at least what you would like to see re: the html/css cleanup
[12:11:15 EDT(-0400)] <ecochran> I think that I have a sense of what you are looking for
[12:11:20 EDT(-0400)] <colinclark> Sure.
[12:11:41 EDT(-0400)] <ecochran> combination of normalization of markup/css and some plug and play markup for developers
[12:11:46 EDT(-0400)] <ecochran> did I capture it?
[12:11:55 EDT(-0400)] <colinclark> I guess for now we won't call these "templates," just to clear.
[12:12:00 EDT(-0400)] <ecochran> yes
[12:12:01 EDT(-0400)] <jacobfarber> right
[12:12:08 EDT(-0400)] <colinclark> Yet I haven't come up with an appropriate name.
[12:12:24 EDT(-0400)] <ecochran> I was thinking of them as "examples"
[12:12:26 EDT(-0400)] <colinclark> Sort of mouldable bits of markup intended to be cut and pasted and modified.
[12:12:27 EDT(-0400)] <jacobfarber> its just a springboard for what we want to deliver
[12:12:33 EDT(-0400)] <colinclark> Yep.
[12:12:44 EDT(-0400)] <ecochran> "sample markup"
[12:12:53 EDT(-0400)] <ecochran> "samples"
[12:12:56 EDT(-0400)] <jacobfarber> would this replace what we see in the online demos?
[12:13:00 EDT(-0400)] <colinclark> So I'd like to have one markup file for each component, and ensure they live at the top level of our components structure, not buried in the samples.
[12:13:19 EDT(-0400)] <colinclark> jacobfarber: At the moment, I see them as augmenting the samples.
[12:13:31 EDT(-0400)] <colinclark> demos, sorry
[12:13:39 EDT(-0400)] <ecochran> I see them as tangential to the demos
[12:13:47 EDT(-0400)] <colinclark> We're trying to make sure there's a good "real world" demonstration of the component.
[12:13:59 EDT(-0400)] <ecochran> wait, that should be the demos
[12:14:01 EDT(-0400)] <colinclark> So as ecochran says, they're complimentary but not necessarily a replacement for those.
[12:14:19 EDT(-0400)] <jacobfarber> so do we need to do heavy modifying to the SVN tree?
[12:14:32 EDT(-0400)] <colinclark> jacobfarber: Nope, it won't require much in the way of modification...
[12:14:43 EDT(-0400)] <colinclark> I'd like to consolidate the Uploader markup into one file, and then promote it up, for example.
[12:14:45 EDT(-0400)] <ecochran> do "markuplets" have to "run"?
[12:14:54 EDT(-0400)] <colinclark> But most of the other markuplets will be new.
[12:15:03 EDT(-0400)] <colinclark> ecochran: Elaborate.
[12:16:17 EDT(-0400)] <ecochran> well, I guess I'm differentiating between code that just runs and code that is ready to run but that you need to customize for your instance or combine with your code
[12:16:31 EDT(-0400)] <colinclark> ecochran: I'm thinking that they should definitely run. They should be a set of nice, working defaults that the implementor can use to get up and running with our components.
[12:16:43 EDT(-0400)] <ecochran> so that the latter might include some stuff like, "PUT YOUR STUFF HERE !!" in the mark up
[12:16:52 EDT(-0400)] <jacobfarber> something someone can just point to, then modify later as needed?
[12:17:01 EDT(-0400)] <colinclark> jacobfarber: Yes, exactly.
[12:17:07 EDT(-0400)] <colinclark> And put their own stuff into.
[12:17:13 EDT(-0400)] <ecochran> then I'm still not sure how this differs from the demos
[12:17:14 EDT(-0400)] <colinclark> So, for example, the LayoutCustomizer.
[12:17:23 EDT(-0400)] <jacobfarber> so their complete encapsulations of that componenet - got it
[12:17:46 EDT(-0400)] <colinclark> The markuplet would provide all the framing for a set of sortable portlets.
[12:17:50 EDT(-0400)] <ecochran> why not just build better, more normalized demos, with better comments
[12:18:22 EDT(-0400)] <ecochran> ?
[12:18:22 EDT(-0400)] <colinclark> The user would grab the markup, stick it into their app. Then they'd start adding and modifying as needed for their app.
[12:18:23 EDT(-0400)] <jacobfarber> im thinking they cant just download an entire demo with comments et al
[12:18:38 EDT(-0400)] <jacobfarber> like to just grab a zip of everythignh and run with it
[12:18:58 EDT(-0400)] <colinclark> ecochran: Well, okay. So this line between demos and samples is a bit blurry...
[12:19:00 EDT(-0400)] <colinclark> one second
[12:20:10 EDT(-0400)] <jacobfarber> for what its worth, it does sounds like these would just be nice, compact demos that are packaged
[12:20:33 EDT(-0400)] <ecochran> one difference is that some of the demos currently have all this "context" which isn't relevant to the average implementor
[12:20:56 EDT(-0400)] <colinclark> There's a really important distinction with types of markup...
[12:21:02 EDT(-0400)] <colinclark> ecochran: Context, yes.
[12:21:02 EDT(-0400)] <ecochran> I think that the examples should be "context-free" or "context-agnostic" but still look really good
[12:21:09 EDT(-0400)] <jacobfarber> i would think there would be a lot of stuff we would need to strip out...
[12:21:12 EDT(-0400)] <colinclark> Those are important to user testing and to realistic development.
[12:21:19 EDT(-0400)] <ecochran> exactly
[12:21:25 EDT(-0400)] <colinclark> In may in fact be that we don't want to consider those "real world" example to be demos.
[12:21:34 EDT(-0400)] <colinclark> Since they're usually more complicated and less clear.
[12:21:35 EDT(-0400)] <ecochran> sorry, I should have said "markuplets" should be...
[12:21:49 EDT(-0400)] <jacobfarber> uPortal sample code is a good example of this
[12:21:55 EDT(-0400)] <colinclark> jacobfarber: Exactly.
[12:21:56 EDT(-0400)] <jacobfarber> uncecessary markup for a demo
[12:22:11 EDT(-0400)] <colinclark> It doesn't really make a great demo, but it does show the range of complexity our components can support, and it is very testable.
[12:22:12 EDT(-0400)] <jacobfarber> ok, this sounds really good
[12:22:16 EDT(-0400)] <colinclark> So, we have:
[12:22:23 EDT(-0400)] <colinclark> 1. Real-world examples.
[12:22:28 EDT(-0400)] <colinclark> 2. Markuplets
[12:22:39 EDT(-0400)] <ecochran> 2 ... need a new name
[12:22:43 EDT(-0400)] <ecochran> but yes
[12:22:48 EDT(-0400)] <colinclark> yes
[12:22:54 EDT(-0400)] <ecochran> is there a 3?
[12:23:06 EDT(-0400)] <colinclark> 3. Insanely simple examples generally used by developers to verify functionality.
[12:23:24 EDT(-0400)] <ecochran> I was going to call those 3. Manual tests
[12:23:25 EDT(-0400)] <jacobfarber> springboards (tongue)
[12:23:26 EDT(-0400)] <colinclark> So 1 is used generally by ourselves... developers and designers to test with.
[12:23:32 EDT(-0400)] <colinclark> 3. Is used only by the geeky
[12:23:54 EDT(-0400)] <colinclark> 2. Is the place in between, where we can show nice demos of our components and will serve as a good starting point for using a component.
[12:23:56 EDT(-0400)] <ecochran> I thought #1 was to show the world how cool this stuff is
[12:23:58 EDT(-0400)] <colinclark> Does this all make sense?
[12:24:01 EDT(-0400)] <jacobfarber> yes
[12:24:08 EDT(-0400)] <jacobfarber> but I think the wiki needs to reflect this
[12:24:13 EDT(-0400)] * jhung (n=Jon@142.150.154.211) has joined #fluid-work
[12:24:18 EDT(-0400)] <colinclark> ecochran: Sure, I suppose it's useful for that, too. But it does depend a bit on audience.
[12:24:22 EDT(-0400)] <jacobfarber> since a lot of people would see these different implementations
[12:24:32 EDT(-0400)] <jacobfarber> and not understand the approach behind it
[12:24:49 EDT(-0400)] <ecochran> do we want to start but cleaning up the current demos or do we want to start fresh?
[12:24:53 EDT(-0400)] <colinclark> Something that is well-presented but not contextual is easier for people to get their heads around in terms of what is the component.
[12:25:04 EDT(-0400)] <jacobfarber> i would recommend starting fresh...
[12:25:12 EDT(-0400)] <colinclark> ecochran: Let's go through it on a component-by-component basis.
[12:25:13 EDT(-0400)] <ecochran> by the way... my intention with the Uploader files was always #2
[12:25:21 EDT(-0400)] <colinclark> Right.
[12:25:49 EDT(-0400)] <colinclark> One big goal for Uploader is to get to a point where we don't have two separate files for the dialog/inline versions.
[12:25:53 EDT(-0400)] <colinclark> It's just too hard to maintain.
[12:26:11 EDT(-0400)] <colinclark> Other goals:
[12:26:14 EDT(-0400)] <ecochran> but there are at least three difference ways to implement uploader
[12:26:21 EDT(-0400)] <ecochran> how do you represent those?
[12:26:26 EDT(-0400)] <colinclark> Three different ways?
[12:26:34 EDT(-0400)] <ecochran> btw: inline, pop-up, portal
[12:26:44 EDT(-0400)] <ecochran> portal is how ATutor is doing it
[12:26:51 EDT(-0400)] <ecochran> or how CARET does it
[12:26:56 EDT(-0400)] <ecochran> although they are not using our code
[12:27:12 EDT(-0400)] <colinclark> ecochran: I'm not sure the markuplet has to be concerned with how it's presented like that.
[12:27:25 EDT(-0400)] <colinclark> We've got to find a way to share that markup.
[12:27:30 EDT(-0400)] <ecochran> but the styling changes....
[12:27:37 EDT(-0400)] <ecochran> subtlly
[12:27:47 EDT(-0400)] <colinclark> Shouldn't the CSS be concerned with that?
[12:27:56 EDT(-0400)] <ecochran> mostly
[12:28:02 EDT(-0400)] <ecochran> some of the buttons are different
[12:28:13 EDT(-0400)] <ecochran> it's a different flow
[12:28:16 EDT(-0400)] <ecochran> in each case
[12:28:19 EDT(-0400)] <colinclark> I think we should work on those variations.
[12:28:28 EDT(-0400)] <ecochran> almost a different pattern
[12:28:30 EDT(-0400)] <colinclark> We have to get away from these separate pages.
[12:28:34 EDT(-0400)] <ecochran> variation on a pattern
[12:28:36 EDT(-0400)] <ecochran> why?
[12:28:38 EDT(-0400)] <colinclark> It's cut-and-paste hell.
[12:28:46 EDT(-0400)] <ecochran> yes, but it's real world
[12:28:53 EDT(-0400)] <colinclark> No, it's not!
[12:28:59 EDT(-0400)] <ecochran> that's a development distinction
[12:29:05 EDT(-0400)] <ecochran> not a UI distintion
[12:29:45 EDT(-0400)] <jacobfarber> this would be a great opportunity to try to solve this issue then
[12:29:50 EDT(-0400)] <ecochran> also by having to maintain different implementations, you end up testing the flexibility of the code
[12:29:55 EDT(-0400)] <jacobfarber> to consolidate the differences
[12:30:16 EDT(-0400)] <ecochran> similar to the problems I found when I had to integrate More Sites with bSpace
[12:30:33 EDT(-0400)] <Bosmon> I think there would be even more tests of flexibility of the code if it were actually easier to maintain different implementation
[12:30:37 EDT(-0400)] <Bosmon> I.e. there would be more of them
[12:30:39 EDT(-0400)] <ecochran> if I'd only done the reference, I never would have found some of the problems that I found
[12:30:52 EDT(-0400)] <colinclark> ecochran: We can't afford to maintain two separate, yet almost entirely duplicated, pieces of markup for the uploader.
[12:31:02 EDT(-0400)] <ecochran> Bosmon: agreed
[12:31:09 EDT(-0400)] <ecochran> colinclark: it's not that hard
[12:31:35 EDT(-0400)] <Bosmon> It is quite hard, for someone other than you, Eli (tongue)
[12:31:50 EDT(-0400)] <Bosmon> But it would be easier, at least, if there were a clearer contract written on what the requirements on this markup actually were
[12:31:59 EDT(-0400)] <Bosmon> And, preferably, these to be as loose as possible
[12:32:04 EDT(-0400)] <ecochran> but if you don't do it, then how do you know that your code still works in the other context
[12:32:07 EDT(-0400)] <ecochran> ?
[12:32:12 EDT(-0400)] <Bosmon> You would write tests!
[12:32:49 EDT(-0400)] <ecochran> We have how many flavors of Reorderer?
[12:33:02 EDT(-0400)] <ecochran> list, portal, gallery...
[12:33:14 EDT(-0400)] <jacobfarber> can I interrupt for a moment?
[12:33:25 EDT(-0400)] <colinclark> jacobfarber: Of course. (smile)
[12:33:28 EDT(-0400)] <ecochran> and I promise you that we'll end up with more than that for inline edit eventually
[12:33:36 EDT(-0400)] <jacobfarber> if im not mistaken, I think we're branching a bit here...
[12:33:55 EDT(-0400)] <Bosmon> I think we are all agreed we want to see any many possible markup variations for all of our components as possible
[12:33:56 EDT(-0400)] <jacobfarber> we can test for flexibility in the code to handle a wide variety of markup approaches
[12:33:56 EDT(-0400)] <ecochran> we are <sheepish>
[12:34:19 EDT(-0400)] <Bosmon> In order to facilitate this variation, we want the requirements on the markup to be both documented and loose
[12:34:20 EDT(-0400)] <jacobfarber> but the deliverable should be a simple, clean example scenario to the implementor
[12:34:51 EDT(-0400)] <jacobfarber> Bosmon: exactly
[12:35:02 EDT(-0400)] <jacobfarber> I think we're covering both bases here
[12:35:09 EDT(-0400)] <Bosmon> And the best way to document and ensure accurate documentation of the allowable markup variations, is, for example, to provide a "canonical" self-rendering example where the component is able to work 100% with user-provided markup...
[12:35:31 EDT(-0400)] <jacobfarber> maintain and hand off a single markup example, but allow almost anythng
[12:35:42 EDT(-0400)] <ecochran> ?
[12:36:49 EDT(-0400)] <colinclark> Let's move forward on the original discussion.
[12:37:18 EDT(-0400)] <jacobfarber> colinclark: eli and I are meeting 1pm our time
[12:37:26 EDT(-0400)] <ecochran> tomorrow
[12:37:28 EDT(-0400)] <jacobfarber> to discuss some ideas and sync up
[12:37:33 EDT(-0400)] <jacobfarber> right
[12:37:33 EDT(-0400)] <colinclark> Great!
[12:37:42 EDT(-0400)] <jacobfarber> so we should be able to make some good headway then
[12:37:48 EDT(-0400)] <colinclark> Good.
[12:38:32 EDT(-0400)] <colinclark> I'd like to see one good "markuplet" for each component.
[12:39:02 EDT(-0400)] <ecochran> makes sense
[12:43:01 EDT(-0400)] <colinclark> Sorry, Jacob and I are having a side conversation about CSS...
[12:43:05 EDT(-0400)] <colinclark> We'll just be a second. (wink)
[12:43:21 EDT(-0400)] <ecochran> bring it to the list! (wink)
[12:44:31 EDT(-0400)] <ecochran> I love talking CSS!
[13:04:25 EDT(-0400)] <colinclark> ecochran: Sorry, we were whiteboarding.
[13:04:34 EDT(-0400)] <jacobfarber> ecochran: we have some goodies for you
[13:04:38 EDT(-0400)] <colinclark> jacobfarber will catch you up on his thinking. (smile)
[13:04:49 EDT(-0400)] <ecochran> cool
[13:05:07 EDT(-0400)] <jacobfarber> so, we can talk a lot more about this tomorrow if you prefer, but here is the gist of what I was thinking:
[13:05:39 EDT(-0400)] <jacobfarber> separating CSS into partitions by function,
[13:06:05 EDT(-0400)] <jacobfarber> actually, let me write this in an emai lto the group, since its a little stretched out
[13:06:27 EDT(-0400)] <ecochran> sounds good... I'll look for the email and talk to you tomorrow
[13:06:36 EDT(-0400)] <jacobfarber> ok
[13:32:44 EDT(-0400)] * ecochran_ (n=ecochran@dwin-wlan-82.AirBears.Berkeley.EDU) has joined #fluid-work
[13:47:24 EDT(-0400)] <Bosmon> We have undoability
[13:47:34 EDT(-0400)] <Bosmon> I am about to merge scads back into trunk...
[14:48:27 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-76.LIPS.Berkeley.EDU) has joined #fluid-work
[15:10:46 EDT(-0400)] <anastasiac> ecochran, do you have any time to help with the Release Notes, with respect to Uploader changes since 0.3?
[15:11:06 EDT(-0400)] <ecochran> it's my intention
[15:11:15 EDT(-0400)] <anastasiac> excellent, thanks
[15:11:42 EDT(-0400)] <ecochran> I'm helping Daphne and Allison with some user testing this afternoon and it's ended up being more time consuming
[15:11:49 EDT(-0400)] <ecochran> than I had thought
[15:20:54 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[15:25:43 EDT(-0400)] <colinclark> jacobfarber: Nice thread on fluid-work. (smile)
[15:33:42 EDT(-0400)] <jacobfarber> thanks!
[15:35:40 EDT(-0400)] <michelled> Bosmon: we are trying to create comprehensive release notes
[15:36:00 EDT(-0400)] <michelled> do you think you could help out with the keyboard a11y plugin API changes?
[15:36:01 EDT(-0400)] <michelled> http://wiki.fluidproject.org/display/fluid/Release+Notes+for+Fluid+Infusion+0.4
[15:40:47 EDT(-0400)] <colinclark> ecochran: I'm doing some JIRA gardening while planning the two upcoming Infusion 0.5 releases. Is this issue fixed? FLUID-1003
[15:40:53 EDT(-0400)] <colinclark> http://issues.fluidproject.org/browse/FLUID-1003
[15:51:28 EDT(-0400)] <ecochran> yes
[15:51:36 EDT(-0400)] <ecochran> sorry, I should have closed it
[15:51:42 EDT(-0400)] <ecochran> or maybe I closed a duplicate
[15:52:00 EDT(-0400)] <colinclark> ecochran: Cool, thanks. Shall I go ahead and resolve it?
[15:52:39 EDT(-0400)] <ecochran> go for it
[16:03:10 EDT(-0400)] <colinclark> jacobfarber: I'm looking at FLUID-985 and its related tasks. What's the latest status on ARIA for the progress bar?
[16:04:18 EDT(-0400)] <jacobfarber> colinclark: JUST as you were typing that, I was prepping a patch for anastasia....
[16:04:30 EDT(-0400)] <colinclark> Impeccable timing, then. (smile)
[16:04:44 EDT(-0400)] <colinclark> Is there more work to be done on this task, do you think?
[16:04:51 EDT(-0400)] <jacobfarber> i have some additions based on what David was telling me about valutext, so after that....
[16:05:17 EDT(-0400)] <jacobfarber> i just need to apply all of this to the sub-progress bars
[16:05:24 EDT(-0400)] <jacobfarber> and then it should be complete
[16:05:35 EDT(-0400)] <colinclark> ecochran: Have you taken a look at this issue? Is it fixed now? http://issues.fluidproject.org/browse/FLUID-660
[16:05:41 EDT(-0400)] <colinclark> jacobfarber: Okay, great.
[16:05:59 EDT(-0400)] <colinclark> jacobfarber: 'll leave it in the plan for 0.5.
[16:07:04 EDT(-0400)] <ecochran> colinclark: checking
[16:07:15 EDT(-0400)] <colinclark> thanks!
[16:08:18 EDT(-0400)] <jacobfarber> colinclark: im just finishing up http://issues.fluidproject.org/browse/FLUID-989
[16:08:34 EDT(-0400)] <colinclark> jacobfarber: Cool.
[16:10:01 EDT(-0400)] <ecochran> colinclark: re: FLUID-660, it is focusable but it doesn't get the focus styling
[16:11:05 EDT(-0400)] <ecochran> colinclark: actually, as I read the bug, it is fixed. I fixed it by putting in an href attribute.
[16:11:09 EDT(-0400)] <ecochran> not ideal but it works
[16:11:53 EDT(-0400)] <colinclark> ecochran: So there is another bug regarding the focus styling, but 660 is fixed?
[16:12:45 EDT(-0400)] <ecochran> colinclark: a) I think so, b) yes
[16:13:11 EDT(-0400)] <colinclark> ecochran: Cool, thanks. Can you resolve the bug and file another one for b)?
[16:13:35 EDT(-0400)] <ecochran> yes
[16:23:09 EDT(-0400)] * michelled (n=team@142.150.154.197) has left #fluid-work
[16:46:07 EDT(-0400)] * athena7_ (n=athena7@99.145.99.32) has joined #fluid-work
[17:08:16 EDT(-0400)] * davidb (n=davidb@bas4-toronto06-1242458989.dsl.bell.ca) has joined #fluid-work
[18:01:56 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-76.LIPS.Berkeley.EDU) has left #fluid-work
[19:18:51 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279722600.dsl.bell.ca) has joined #fluid-work