[08:22:25 CDT(-0500)] <colinclark> Justin_o: So what's your take on the Progress issues and our two possible solutions?
[08:24:48 CDT(-0500)] <Justin_o> colinclark: hello, i should probably respond to that e-mail..
[08:24:58 CDT(-0500)] <colinclark> Yeah, I was thinking of doing the same
[08:25:06 CDT(-0500)] <colinclark> But I was curious about your early thoughts
[08:25:18 CDT(-0500)] <colinclark> I guess, in the end, this all stems from a bug in NVDA with Firefox, is that right?
[08:25:27 CDT(-0500)] <colinclark> (if I'm reading Golam's table properly)
[08:25:42 CDT(-0500)] <colinclark> It'd be cool if he was here in the channel and we could chat through it a bit at some point today
[08:25:44 CDT(-0500)] <Justin_o> yes that's correct
[08:25:47 CDT(-0500)] <colinclark> I'll be working from home today
[08:25:56 CDT(-0500)] <Justin_o> Golam's not in yet
[08:25:58 CDT(-0500)] <Justin_o> okay...
[08:26:02 CDT(-0500)] <colinclark> ok, cool
[08:26:10 CDT(-0500)] <Justin_o> i think the first option is a little better because it is more like what users would be familiar with
[08:26:12 CDT(-0500)] <colinclark> And NVDA acknowledges it's their bug, right?
[08:26:32 CDT(-0500)] <Justin_o> colinclark: pretty much yes, i e-mailed them and they said to file it.. so i have
[08:26:37 CDT(-0500)] <colinclark> Cool
[08:26:38 CDT(-0500)] <Justin_o> not much response besides
[08:26:43 CDT(-0500)] <colinclark> So, to summarize
[08:26:50 CDT(-0500)] <colinclark> 1. Everything works great in JAWS?
[08:27:17 CDT(-0500)] <Justin_o> well.. works... it just says something like "52"
[08:27:40 CDT(-0500)] <colinclark> ok
[08:27:52 CDT(-0500)] <Justin_o> so we lose the descriptiveness that we had added with the value-text
[08:27:55 CDT(-0500)] <colinclark> Right
[08:27:59 CDT(-0500)] <colinclark> Sorry, I should be more clear
[08:28:10 CDT(-0500)] <colinclark> 1. As it is today, without this change, everything works great in JAWS?
[08:28:17 CDT(-0500)] <Justin_o> ah... yes
[08:28:19 CDT(-0500)] <Justin_o> well...
[08:29:00 CDT(-0500)] <Justin_o> it's not so good at announcing the completion
[08:29:19 CDT(-0500)] <Justin_o> so with the speed that the demo works at you hear 1 or 2 progress announcements and that's it
[08:29:22 CDT(-0500)] <colinclark> How come? Just because it's not so good at it? Or is it something we're doing/not doing?
[08:30:12 CDT(-0500)] <Justin_o> I think it's JAWS. the code looks correct.. i think what it does is that if it finishes before it's ready to announce the next progress state, it just ignores it
[08:30:32 CDT(-0500)] <colinclark> Annoying. Is that with JAWS 11?
[08:31:05 CDT(-0500)] <Justin_o> I've had that with Jaws 10, I'll have to double check with Golam which version he was using... but i think it was 10
[08:31:43 CDT(-0500)] <colinclark> Ok
[08:31:51 CDT(-0500)] <colinclark> So walk me through the cons of the live region scenario?
[08:33:49 CDT(-0500)] <Justin_o> 1) we would have to add a bunch of code, that we may just drop when NVDA fixes their bug.
[08:34:32 CDT(-0500)] <Justin_o> 2) the live region approach queues up the announcements, which in the demo causes the progress to continue to announce after it has actually finished...
[08:35:07 CDT(-0500)] <Justin_o> 3) It is a different semantic that what users may be expecting (although this may be a better one)
[08:35:45 CDT(-0500)] <Justin_o> I think those are the main ones...
[08:36:11 CDT(-0500)] <Justin_o> oh and in JAWS on IE, I think the live region is ignored and it just announces the value-now anyways...
[08:37:09 CDT(-0500)] <colinclark> Justin_o: ok, that's very helpful
[08:37:17 CDT(-0500)] <colinclark> So, the real question I have...
[08:37:30 CDT(-0500)] <colinclark> I'm thinking we would like to make at least one implementation exemplary
[08:37:39 CDT(-0500)] <colinclark> Even if both JAWS and NVDA are clearly still pretty buggy
[08:38:04 CDT(-0500)] <colinclark> But, if I understand things right, it's virtually impossible to do this in an appealing way right now?
[08:38:20 CDT(-0500)] <colinclark> Is there any option that provides decent user experience?
[08:38:47 CDT(-0500)] <Justin_o> colinclark: there's no perfect solution... i think we would have to know from users what they like best...
[08:39:22 CDT(-0500)] <Justin_o> If i had to choose now though, I would lean towards what is more consistent with the progress indicators they are used to
[08:40:20 CDT(-0500)] <colinclark> Do you or Golam have a copy of ORCA kicking around anywhere?
[08:40:23 CDT(-0500)] <Justin_o> I think we might be able to make things a little better by having a live region to indicate when progress has finished... so after the progress bar has finished... it triggers a live region with some completion message
[08:40:36 CDT(-0500)] <Justin_o> colinclark: don't think so, but it shouldn't be too hard to get
[08:41:06 CDT(-0500)] <colinclark> Golam's running Ubuntu on his machine now, so it's probably really easy for him to get it up and running
[08:41:14 CDT(-0500)] <colinclark> Let's give ORCA a shot to see what happens
[08:41:31 CDT(-0500)] <colinclark> I'm acronymizing it, but I don't know if that is actually appropriate
[08:41:36 CDT(-0500)] <colinclark> It's probably just Orca
[08:41:41 CDT(-0500)] <colinclark> without the screaming
[08:42:54 CDT(-0500)] <colinclark> Okay, so next steps as I see them:
[08:43:02 CDT(-0500)] <colinclark> 1. Try Orca, see how it goes
[08:43:31 CDT(-0500)] <colinclark> 2. I'll tweet about the trouble we're facing--if I can summarize it in 140 characters and we'll see if anyone else has any advice or preferences
[08:43:56 CDT(-0500)] <colinclark> 3. Let's pick an approach that gives basic usability for now, and when NVDA fixes their bug, we'll add back the valuetext
[08:44:06 CDT(-0500)] <colinclark> Justin_o: Does that sound about right? Anything I'm missing?
[08:45:07 CDT(-0500)] <Justin_o> colinclark: that sounds good.. actually Golam has a patch for option one up on the jira now i think
[08:45:13 CDT(-0500)] <colinclark> ok, cool
[08:45:32 CDT(-0500)] <colinclark> I guess we should provide a link to this chat in respond to Golam's list email, with a little summary
[08:45:35 CDT(-0500)] <colinclark> I can do that if you want
[08:47:55 CDT(-0500)] <Justin_o> colinclark: sure, thanks
[08:48:11 CDT(-0500)] <colinclark> golam: Hey!
[08:48:20 CDT(-0500)] <golam> Hi Colin
[08:49:16 CDT(-0500)] <colinclark> Justin_o and I were just chatting about the Progress issues with NVDA and JAWS
[08:49:27 CDT(-0500)] <colinclark> I was trying to understand all the problems in a bit more detail
[08:49:28 CDT(-0500)] <golam> ok cool
[08:50:06 CDT(-0500)] <colinclark> I'll just dig you up a link to the chat logs
[08:50:13 CDT(-0500)] <colinclark> Wiki's slow, as always
[08:50:22 CDT(-0500)] <golam> ok
[08:50:46 CDT(-0500)] <colinclark> http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2010-09-21
[08:50:55 CDT(-0500)] <colinclark> So, you've done some nice work here, golam
[08:51:08 CDT(-0500)] <colinclark> Seems like we're in a tough spot with poor screen reader implementations
[08:51:47 CDT(-0500)] <golam> thanks team effort
[08:52:00 CDT(-0500)] <colinclark> I'm thinking we should give Orca a spin and see if it's doing any better
[08:52:14 CDT(-0500)] <colinclark> I'm hoping we might be able to get one exemplary implementation working to start
[08:52:28 CDT(-0500)] <colinclark> Figuring that NVDA will eventually fix their bug and that JAWS is, well, JAWS.
[08:52:33 CDT(-0500)] <colinclark> What version of JAWS were you using?
[08:52:53 CDT(-0500)] <jamon> colinclark: are you at 205? fast for me
[08:53:04 CDT(-0500)] <golam> jaws 10
[08:53:18 CDT(-0500)] <colinclark> jamon: I'm at home. I keep hearing you say "fast for me," but I keep seeing the general consensus that wiki is pretty slow.
[08:53:25 CDT(-0500)] <colinclark> I have no doubt that networks are like that
[08:53:32 CDT(-0500)] <colinclark> But it does seem to have its slow moments
[08:53:46 CDT(-0500)] <colinclark> golam: Is there a JAWS 11 demo available for you to also try?
[08:53:52 CDT(-0500)] <colinclark> They might have improved it a bit
[08:53:58 CDT(-0500)] <jhung> jameswy: do you have some time to talk about WCAG2 colour picking?
[08:54:03 CDT(-0500)] <jamon> 500ms load time from montreal colinclark for that irc log page
[08:54:07 CDT(-0500)] <golam> I didn't try with Orca
[08:54:15 CDT(-0500)] <golam> I mean test*
[08:54:21 CDT(-0500)] <jameswy> jhung: yep
[08:54:29 CDT(-0500)] <colinclark> jamon: Sure beats what I was seeing. Oh well.
[08:54:41 CDT(-0500)] <colinclark> golam: Ok. Give Orca a try to start, and we'll see how it sounds.
[08:54:52 CDT(-0500)] <jameswy> jhung: also, are we still meeting harriswong and Cindy about builder this morning?
[08:54:57 CDT(-0500)] <jamon> couple more days and we'll have our servers back online colinclark
[08:55:04 CDT(-0500)] <colinclark> jamon: wicked!
[08:55:34 CDT(-0500)] <jhung> jameswy: I hope so. Didn't get a response from C&H.
[08:55:53 CDT(-0500)] <jhung> harriswong: are you available at 10:30a to talk about the builder design?
[08:56:22 CDT(-0500)] <jameswy> jhung: He's watching a video right now. I'll just shout across the room,
[08:56:44 CDT(-0500)] <jhung> jameswy: or throw something... or send the flies to deliver the message.
[08:57:33 CDT(-0500)] <jameswy> jhung: they didn't get the email (I think you sent it to their utor)
[08:58:01 CDT(-0500)] <jhung> jameswy: argh...
[08:58:12 CDT(-0500)] <jhung> jameswy: I mean, blarg.
[08:58:43 CDT(-0500)] <jhung> I'll email them properly now...
[09:01:05 CDT(-0500)] <colinclark> Justin_o: On anther note, I've been looking at the Uploader, getting it ready for the HTML 5 work
[09:01:28 CDT(-0500)] <justin_o> colinclark: great.. i saw you committed some clean up
[09:01:43 CDT(-0500)] <colinclark> As I look at it, I realize it's one of those classic situations where you think several things are really one thing, and everything starts to glob together.
[09:02:01 CDT(-0500)] <colinclark> So, for the Flash implementation, there are really three distinct concerns
[09:02:11 CDT(-0500)] <colinclark> But only two objects, fuzzily factored
[09:03:04 CDT(-0500)] <justin_o> ah okay...
[09:03:10 CDT(-0500)] <golam> Colin: I will test with Orca and let you guys know how it went.
[09:03:17 CDT(-0500)] <colinclark> There's the code that handles the mechanics of getting files up to the server and listening for various events (the manager), there's the code that is responsible for tweaking the DOM to get Flash all set up, and then there's a missing responsibility: setting up SWFUpload based on configuration from both of the other objects
[09:03:24 CDT(-0500)] <colinclark> golam: Great, thanks.
[09:03:34 CDT(-0500)] <golam> welcome
[09:03:50 CDT(-0500)] <colinclark> In other words, SWFUpload started the whole mess by mixing together model configuration with view-related configuration when Flash 10 came out and complicated things
[09:04:12 CDT(-0500)] <colinclark> So, I'll do this refactoring now, since it will simplify things substantially for HTML 5
[09:04:33 CDT(-0500)] <colinclark> And then I'll write a function that converts old-style options to the new style in hopes of maintaining full API backwards compatibility.
[09:05:27 CDT(-0500)] <jameswy> jhung: did you want to talk WCAG compliant colours now, or after chatting with harriswong and Cindy?
[09:05:42 CDT(-0500)] <justin_o> colinclark: interesting... will that be all the "foundation" repairs that are needed?
[09:06:00 CDT(-0500)] <colinclark> Justin_o: As far as I can tell, yes
[09:06:40 CDT(-0500)] <colinclark> There is a bit of tidying up related to the File Queue object... there is code scattered in a few places that is really generic and should be located in it. But that will become clear while actually implementing the new HTML 5 manager.
[09:07:03 CDT(-0500)] <jhung> jameswy: maybe we can talk a little about it now.
[09:07:42 CDT(-0500)] <jameswy> jhung: alrighty. Give me a ring whenever you're ready.
[09:07:48 CDT(-0500)] <jhung> k
[09:08:39 CDT(-0500)] <justin_o> colinclark: cool, do you think it will be a few more days before you are ready to buddy up?
[09:08:55 CDT(-0500)] <colinclark> Hopefully I can square it away today
[09:09:00 CDT(-0500)] <colinclark> If not, I can still always use a buddy
[09:10:55 CDT(-0500)] <justin_o> colinclark: good... soon I'll be letting you have some of your friends back..
[09:14:03 CDT(-0500)] <jhung> jameswy: Here's the WebAim WCAG 2 colour article: http://webaim.org/blog/wcag-2-0-and-link-colors/
[09:14:36 CDT(-0500)] <colinclark> Justin_o: Can't wait
[09:15:43 CDT(-0500)] <colinclark> Hey, for those of you interested in Canvas a11y, the "shadow DOM" technique we've been talking about for awhile is now implemented in, of all things, IE 9: http://www.paciellogroup.com/blog/?p=670
[09:16:33 CDT(-0500)] <harriswong> jhung: sorry i didn't see the msg, it didn't ping me on 'harriswong'. i
[09:16:54 CDT(-0500)] <harriswong> jhung: i'm good to meet @ 10:30am
[09:17:14 CDT(-0500)] <jhung> harriswong: cool. Thanks!
[09:31:29 CDT(-0500)] <jhung> harriswong: I won't have you on my skype. Add me - jhung_ca
[10:51:28 CDT(-0500)] <athena> if anyone's around this morning i'm having some issues figuring out the best way to handle event wiring for subcomponents
[11:21:31 CDT(-0500)] <justin_o> Bosmon: hello...
[11:21:34 CDT(-0500)] <Bosmon> Hello justin_o and mlam, I am here now
[11:21:44 CDT(-0500)] <justin_o> wondering if you could give us a bit of a hand with our Dead Man's Blur
[11:21:48 CDT(-0500)] <mlam> hi bosmon
[11:22:09 CDT(-0500)] <justin_o> Bosmon: mlam has some code that he can show you... he's just getting it up on pastebin
[11:22:38 CDT(-0500)] <Bosmon> Oh wait
[11:22:44 CDT(-0500)] <Bosmon> I just discovered I already had a copy of irc running
[11:22:47 CDT(-0500)] <Bosmon> Let me close this one
[11:23:22 CDT(-0500)] <justin_o> Bosmon: while we are waiting... i was chatting with anastasiac about the dead man's blur... she is also using it in cspace for something other than inline edit... thta's why she was thinking we should move it to the framework
[11:23:57 CDT(-0500)] <mlam> Bosmon: I've posted our bindMouseHandlers function to pastebin
[11:23:57 CDT(-0500)] <mlam> http://fluid.pastebin.com/uFqmzQQR
[11:25:54 CDT(-0500)] <Bosmon> I think I am here now
[11:27:09 CDT(-0500)] <justin_o> Bosmon: welcome back
[11:27:47 CDT(-0500)] <justin_o> would you like us to repost our comments or did you want to read the log?
[11:36:22 CDT(-0500)] <Bosmon> Ok, let me try to find the log
[11:37:41 CDT(-0500)] <Bosmon> Yes, so, deadMan's blur should be improved a bit if it is going to be elevated into the core framework
[11:38:12 CDT(-0500)] <Bosmon> It was awaiting refactoring into one component "deadMan's X" that will apply a dead man's X for any X
[11:38:18 CDT(-0500)] <Bosmon> And then a configuration particularly for blur
[11:38:32 CDT(-0500)] <Bosmon> And then it needs to be reformed so that the way it is applied to inlineEdit is more declarative
[11:38:46 CDT(-0500)] <Bosmon> Really it should actually be a component... and perhaps even instantiated using IoC
[11:38:55 CDT(-0500)] <justin_o> Bosmon: interesting, makes sense.. guess it won't be a 1.3 change though eh
[11:39:11 CDT(-0500)] <Bosmon> Well, unless one of this team wants to take it up
[11:39:16 CDT(-0500)] <justin_o>
[11:39:24 CDT(-0500)] <Bosmon> So, what seems to be the problem with the bindMouseHandlers function
[11:39:30 CDT(-0500)] <justin_o> maybe i'll add it to the nice to have section..
[11:39:38 CDT(-0500)] <justin_o> okay..
[11:39:55 CDT(-0500)] <Bosmon> Well, by eye, the configuration looks wrong
[11:40:02 CDT(-0500)] <Bosmon> In that it is not using "blurHandlerBinder"
[11:40:08 CDT(-0500)] <Bosmon> Which implies that it will not displace the default blur handler
[11:40:20 CDT(-0500)] <justin_o> ah
[11:40:21 CDT(-0500)] <justin_o> okay
[11:40:29 CDT(-0500)] <Bosmon> Oh wait, this is code which is considered a patch for the core component?
[11:40:37 CDT(-0500)] <justin_o> yes
[11:40:49 CDT(-0500)] <Bosmon> In that case this is also wrong, this needs to be packaged as configuration which can be adjusted
[11:41:09 CDT(-0500)] <justin_o> um... what do you mean by that
[11:41:16 CDT(-0500)] <justin_o> there is configuration to show the button or not
[11:41:21 CDT(-0500)] <Bosmon> Well, you should follow the pattern established by the existing inlineEditIntegrations
[11:41:30 CDT(-0500)] <Bosmon> The user should have control over the blurHandler, etc.
[11:41:39 CDT(-0500)] <Bosmon> Anyway, you said you had a problem with your "that"?
[11:42:15 CDT(-0500)] <Bosmon> We probably actually need to break out the whole blurHandler infrastructure now - consider the case that the user is ALREADY using one of the integrations
[11:42:20 CDT(-0500)] <Bosmon> You require to make all of those accessible too
[11:42:28 CDT(-0500)] <justin_o> yes... they are undefined... but it looks like they should be in scope
[11:42:37 CDT(-0500)] <Bosmon> Can you be more specific?
[11:43:31 CDT(-0500)] <justin_o> okay... on instantiation, the that's are defined... but when you try to use it, they aren't... meaning when the blur is called they aren't defined
[11:43:34 CDT(-0500)] <Bosmon> So, there really needs to be an exposed piece of configuration which consists of "deadMan's blur exceptions"
[11:43:57 CDT(-0500)] <justin_o> ah ... i see that makes sense
[11:44:24 CDT(-0500)] <Bosmon> I suggest that you make this a "free hash" of targets so that it can participate in options merging
[11:44:37 CDT(-0500)] <Bosmon> So, which line gives an error
[11:44:56 CDT(-0500)] <justin_o> Bosmon: can we create you a patch and send you the code?
[11:45:01 CDT(-0500)] <Bosmon> ok
[11:45:25 CDT(-0500)] <justin_o> Bosmon: mlam is making you a patch
[11:45:45 CDT(-0500)] <justin_o> so i think we want the default inline edit to have the accessibility fix...
[11:46:08 CDT(-0500)] <Bosmon> Well, for sure
[11:46:12 CDT(-0500)] <Bosmon> But you need all the others to have it too
[11:46:27 CDT(-0500)] <justin_o> i don't think we want to make users have to go through the inlineEdit integrations to have to get an accessible version
[11:46:29 CDT(-0500)] <justin_o> yes... that is true
[11:46:42 CDT(-0500)] <justin_o> so we need to have it in a place where all the versions have access
[11:48:32 CDT(-0500)] <mlam> Bosmon: patch sent
[11:49:18 CDT(-0500)] <Bosmon> Well, I think you misinterpreted me...
[11:49:27 CDT(-0500)] <justin_o> oh
[11:49:29 CDT(-0500)] <justin_o> sorry
[11:49:37 CDT(-0500)] <Bosmon> I was meaning, that this work needs to be packaged as configuration "in the same way that an integration is"
[11:49:49 CDT(-0500)] <Bosmon> Otherwise, there's clearly no way it can participate in integration
[11:51:06 CDT(-0500)] <justin_o> hmm... how do we package it as an integration, would we have to make one for every version of the inline edit... i think that some of the integrations use a different blurhandlebinder
[11:51:36 CDT(-0500)] <Bosmon> Yes, this is what I mean about breaking out the deadMan's configuration
[11:51:57 CDT(-0500)] <Bosmon> Now the "core component" is likely to use it too, its configuration needs to become a standard top-level element of the component's configuration
[11:52:11 CDT(-0500)] <Bosmon> Rather than an "opaque alternative" blurHandlerBinder that the integrations might use
[11:52:39 CDT(-0500)] <Bosmon> So - for example, imagine the user had asked for an accessible selection inline edit component
[11:53:00 CDT(-0500)] <Bosmon> The "dead man's set" now needs to consist of TWO elements, accumulated from two bodies of code, one from the core component, one from the integration
[11:56:12 CDT(-0500)] <justin_o> okay.. i think i'm starting to understand this... so we provide the arguements to the deadmans blur as configuration...
[11:58:19 CDT(-0500)] <Bosmon> So, for a start, which line will the patched version fail on?
[12:01:45 CDT(-0500)] <justin_o> well the deadmansblur doesn't seem to be working...
[12:02:05 CDT(-0500)] <justin_o> Bosmon: mlam is hunting down the line number again
[12:07:36 CDT(-0500)] <justin_o> Bosmon: if you look at the demo code, you can see we've added a new example with the button visible, when you click on the button you hit an error in the jquery file, where that is not defined. line 339 in InlineEdit.js, line 1594 jquery.js
[12:10:16 CDT(-0500)] <Bosmon> Could you talk Mike through how to make patches?
[12:10:22 CDT(-0500)] <Bosmon> This one has been made relative to the whole workspace
[12:10:41 CDT(-0500)] <justin_o> oops.. sorry i blame eclipse for bad defaults
[12:11:24 CDT(-0500)] <Bosmon> Yes, and unfortunately you get the same default every time you make a patch
[12:11:26 CDT(-0500)] <mlam> Do you want me to mail you another patch?
[12:11:34 CDT(-0500)] <Bosmon> It's ok, I can read this one
[12:11:37 CDT(-0500)] <Bosmon> Although I can't apply it
[12:11:46 CDT(-0500)] <mlam> ok, sorry about that
[12:12:48 CDT(-0500)] <Bosmon> Also, please talk Mike through how to configure Eclipse without tabs
[12:12:50 CDT(-0500)] <mlam> I sent you the new patch anyways...done properly this time
[12:13:33 CDT(-0500)] <Bosmon> Perhaps we should have a new wiki page
[12:13:43 CDT(-0500)] <Bosmon> "Getting ready to work on the framework with Eclipse"
[12:14:11 CDT(-0500)] <justin_o> Bosmon: yes... eclipse is horrible when you have to start changing settings
[12:17:25 CDT(-0500)] <Bosmon> So... the example sort of works for me
[12:17:31 CDT(-0500)] <justin_o> Bosmon: really...
[12:17:34 CDT(-0500)] <Bosmon> I guess you'll need to be more specific about the what problem you are seeing
[12:17:51 CDT(-0500)] <Bosmon> For example, how can you be seeing a stack trace which includes line 339 of InlineEdit together with a line from jquery?
[12:18:00 CDT(-0500)] <Bosmon> There are no calls to jquery on that line
[12:18:08 CDT(-0500)] <justin_o> Bosmon: so click the "Edit Text" button to ender edit mode, then click "save text" to try to exit edit mode
[12:18:22 CDT(-0500)] <Bosmon> Also, line 339 doesn't execute when you click the button
[12:18:53 CDT(-0500)] <justin_o> yep, i think the trace route may have goon back to there... or maybe more correctly to the deadmansblur code that executes
[12:19:01 CDT(-0500)] <Bosmon> aha, ok
[12:19:28 CDT(-0500)] <Bosmon> Well, deadmansblur doesn't reference "that"
[12:19:32 CDT(-0500)] <Bosmon> So that doesn't make any sense either
[12:20:20 CDT(-0500)] <justin_o> well... it doesn't explicitly reference that.. but aliases the call to it... so that.editField is the offender
[12:20:47 CDT(-0500)] <Bosmon> So, the example runs for me... but as you say deadMansBlur doesn't operate
[12:21:00 CDT(-0500)] <Bosmon> But this is as I explained because you have not displaced the existing blur handler
[12:21:00 CDT(-0500)] <justin_o> which in our case is used as the control argument to deadmansblur
[12:21:09 CDT(-0500)] <justin_o> right
[12:21:18 CDT(-0500)] <justin_o> okay... so that is where this all comes from
[12:21:23 CDT(-0500)] <justin_o>
[12:21:51 CDT(-0500)] <justin_o> okay.. so we need to refactor the component to take in config options for the bindblurhandler
[12:22:05 CDT(-0500)] <justin_o> which the defaults will be what is used by the core component
[12:22:05 CDT(-0500)] <Bosmon> I can't reproduce your failure to find the editField
[12:22:09 CDT(-0500)] <justin_o> really
[12:22:29 CDT(-0500)] <Bosmon> Well, it's sort of impossible
[12:22:41 CDT(-0500)] <Bosmon> I can't make sense of the way in which you say you are getting it
[12:22:53 CDT(-0500)] <Bosmon> You say it only occurs when operating the button
[12:23:02 CDT(-0500)] <Bosmon> But then reference a line of code which doesn't execute then...
[12:23:02 CDT(-0500)] <justin_o> maybe it's a linux thing.. i'll try to apply the patch and run it on mac os
[12:28:03 CDT(-0500)] <justin_o> okay... i just tried it on firefox on the mac... i think we were being misled by the debugger in chrome
[12:28:42 CDT(-0500)] <justin_o> but it's still not working anyways
[12:29:02 CDT(-0500)] <justin_o> Bosmon: so i guess it has to do with the not getting rid of the other blur handler like you were mentioning
[12:30:39 CDT(-0500)] <athena> Bosmon: i don't want to interrupt right now, but if you have some time later i have some questions about wiring together events in nested components
[12:31:16 CDT(-0500)] <Bosmon> Hi there athena
[12:31:57 CDT(-0500)] <athena> hello
[12:33:26 CDT(-0500)] <Bosmon> I guess you haven't asked your question yet, but I think I could make a guess what it is about
[12:33:32 CDT(-0500)] <athena> oh?
[12:33:55 CDT(-0500)] <Bosmon> An important strategy in complex components is arranging to "share" the overall "events" object
[12:34:00 CDT(-0500)] <Bosmon> Is this along the right lines?
[12:34:05 CDT(-0500)] <athena> i'm not sure - might be
[12:34:23 CDT(-0500)] <athena> basically the use case is that we have some components that are sometimes used standalone, and sometimes used as subcomponents
[12:34:35 CDT(-0500)] <athena> so i want to make sure they can continue to live on their own
[12:34:56 CDT(-0500)] <athena> but i also need them to have some sort of onLoad type initialization event so they can report back to any parent that they're initialized
[12:35:06 CDT(-0500)] <athena> certainly configuring an onLoad method in itself is easy
[12:35:20 CDT(-0500)] <athena> but the logic that needs to be executed typically then needs access to the calling parent component
[12:35:25 CDT(-0500)] <Bosmon> Right
[12:35:27 CDT(-0500)] <athena> so the parent that instance
[12:35:36 CDT(-0500)] <Bosmon> Sounds like you need our brand-new hot-off-the-press IoC functionality
[12:35:49 CDT(-0500)] <Bosmon> "Configure your components at a single bound, in a context-aware manner"
[12:35:54 CDT(-0500)] <athena> so i read through your email about that from aug, and it did indeed seem related
[12:36:15 CDT(-0500)] <athena> but the examples i saw didn't really seem to relate to events specifically, so i wasn't sure how to handle that
[12:36:20 CDT(-0500)] <Bosmon> This is in trunk now, although I guess you won't get access to it until the next framework realease
[12:36:34 CDT(-0500)] <athena> yeah - we unfortunately need something that'll work now
[12:36:38 CDT(-0500)] <Bosmon> Well, event listeners can be configured through component options, so they can be reached by the same scheme
[12:36:51 CDT(-0500)] <Bosmon> Anyway, yes
[12:36:58 CDT(-0500)] <athena> though that's really good to know about, and if the end answer is that we should just make it work for now and re-evaluate in a few months that's totally fine
[12:37:07 CDT(-0500)] <athena> so i can wire up event listeners through the options
[12:37:13 CDT(-0500)] <Bosmon> When you say the logic needs access to the parent component - is this more than just the logic in the event handler?
[12:37:41 CDT(-0500)] <athena> but how would i make sure that the event listener can get access to the parent that instance?
[12:37:52 CDT(-0500)] <athena> should i be passing the parent that into the subcomponent initialization?
[12:37:54 CDT(-0500)] <Bosmon> Well, the event listener should be supplied from the parent that
[12:38:53 CDT(-0500)] <Bosmon> In general, as you say, you can't pass the parent into the subcomponent without polluting it
[12:39:35 CDT(-0500)] <athena> i guess that's a lot of my concern
[12:39:43 CDT(-0500)] <athena> plus it gets ambiguous with multiple levels of nesting
[12:40:22 CDT(-0500)] <Bosmon> I guess we'd need to go through some specific examples
[12:40:29 CDT(-0500)] <Bosmon> In general only listeners should go "down the grain"
[12:41:13 CDT(-0500)] <Bosmon> A parent component can contribute a listener to a child component, which will then execute in the context of the parent
[12:41:26 CDT(-0500)] <athena> so how would i do that?
[12:41:29 CDT(-0500)] <athena> i saw the addListener method
[12:41:34 CDT(-0500)] <athena> which actually seems kind of like what i want
[12:41:43 CDT(-0500)] <Bosmon> Yes, you can also do this declaratively via the "listeners" block in a component's options
[12:42:01 CDT(-0500)] <Bosmon> Anything supplied there will automatically be added as a listener to the event with the matching name
[12:42:11 CDT(-0500)] <athena> but you can only add listeners after the component is initialized, which is tough with my intialization event use case
[12:42:19 CDT(-0500)] <athena> yeah - i'd like to do this all declaratively
[12:42:25 CDT(-0500)] <athena> for maximum configuration and such
[12:42:28 CDT(-0500)] <Bosmon> Yes, the other good part of the "listeners" block is that it executes BEFORE initialization completes
[12:42:37 CDT(-0500)] <athena> right
[12:42:37 CDT(-0500)] <Bosmon> In fact it executes when the subcomponent invokes initView
[12:42:43 CDT(-0500)] <athena> yes
[12:43:08 CDT(-0500)] <athena> so right now i have most of this stuff wired as declarative listeners, but i had to pass the parent component into the creation of the subcomponent to do it
[12:43:39 CDT(-0500)] <Bosmon> Ok, so why was that?
[12:44:37 CDT(-0500)] <athena> basically i want the subcomponent to say "ok, i'm all initialized, you can call my methods now"
[12:44:49 CDT(-0500)] <Bosmon> hmm... but surely that is what the listener is for
[12:44:54 CDT(-0500)] <athena> and the parent component to do stuff stuff once it knows that the child's ajax calls and such are all finished
[12:44:58 CDT(-0500)] <athena> right
[12:45:14 CDT(-0500)] <Bosmon> The subcomponent exposes an event, which it fires once it is ready... and the parent can contribute a listener to this via "listeners"
[12:45:30 CDT(-0500)] <athena> so i had to tell the subcomponent about the parent in the initialization method so it could pass the parent "that" instance back as one of the event method parameters
[12:45:40 CDT(-0500)] <Bosmon> Although I'm worried that the point after subcomponent initialisation might be too late for you.... is it the case that some of the ajax might complete synchronously in some cases?
[12:45:49 CDT(-0500)] <Bosmon> OK, so you don't need to do that
[12:46:01 CDT(-0500)] <Bosmon> You can just contextualise the listener by defining it in a closure where the parent is visible
[12:46:21 CDT(-0500)] <athena> yes - i've done that in other places too, and that seems to kinda work
[12:46:32 CDT(-0500)] <Bosmon> Either by writing it inline in the parent creator, or by manufacturing it with a higher-order function
[12:46:37 CDT(-0500)] <athena> though that probably makes it impossible for someone else to override it, i'd think?
[12:46:53 CDT(-0500)] <Bosmon> Well, the contribution of the listener to the options can be overidden
[12:46:54 CDT(-0500)] <athena> since they'd be writing their custom implementation outside of that method
[12:47:07 CDT(-0500)] <Bosmon> Clearly you can't override the implementation of the listener since it is bound permanently to the parent component
[12:47:28 CDT(-0500)] <Bosmon> You can construct a "listener make function" if you want
[12:47:39 CDT(-0500)] <athena> listener make function?
[12:47:47 CDT(-0500)] <Bosmon> That will let people in the outside work construct listeners bound to different environments
[12:47:51 CDT(-0500)] <Bosmon> I meant "maker"...
[12:47:55 CDT(-0500)] <athena> hmmm
[12:47:55 CDT(-0500)] <athena> so
[12:49:12 CDT(-0500)] <athena> yeah
[12:49:13 CDT(-0500)] <colinclark> Looks like a good topic, I'll catch up in the logs
[12:49:24 CDT(-0500)] <colinclark> How was your vacation, athena?
[12:49:26 CDT(-0500)] <athena> awesome
[12:49:28 CDT(-0500)] <Bosmon> I was sucked in here to help KINGG and Mike deal with InlineEdit stuf
[12:49:29 CDT(-0500)] <athena> oregon's really pretty
[12:49:37 CDT(-0500)] <athena> i think we've all been pretty busy
[12:49:43 CDT(-0500)] <athena> and i keep getting sick
[12:49:47 CDT(-0500)] <colinclark> sucks
[12:49:55 CDT(-0500)] <athena> yes
[12:49:59 CDT(-0500)] <Bosmon> I had sort of forgotten I had this chat running for months... it got lost in the Windows 7 interface
[12:50:03 CDT(-0500)] <Bosmon> Sorry to hear you have been sickk
[12:50:10 CDT(-0500)] <athena> lol - glad you're back
[12:50:11 CDT(-0500)] <athena> it's ok
[12:50:22 CDT(-0500)] <athena> i guess working from home and not getting out enough kept me away from germs for a few years
[12:50:31 CDT(-0500)] <athena> now i ride the bus to do cool stuff all the time
[12:50:54 CDT(-0500)] <athena> so at least it's for a good reason
[12:51:05 CDT(-0500)] <athena> i'll be really interested to see how the stuff you're working on in trunk shapes up Bosmon
[12:51:46 CDT(-0500)] <athena> looks like you guys have a lot of releases planned soon
[12:53:48 CDT(-0500)] <Bosmon> Yes, it will be a busy time
[12:55:20 CDT(-0500)] <athena> good stuff though
[12:55:27 CDT(-0500)] <athena> and hopefully we can get some of it into the next release of up
[13:00:41 CDT(-0500)] <Bosmon> Here is a particularly magnificent use of higher-order functions.....
[13:00:43 CDT(-0500)] <Bosmon> fluid.each(resourceSpecs, function(spec) {
[13:00:43 CDT(-0500)] <Bosmon> spec.options.success = cspace.util.composeCallbacks(spec.options.success, indicator.update);
[13:00:43 CDT(-0500)] <Bosmon> });
[13:00:55 CDT(-0500)] <Bosmon> Showing also the giant benefits of DECLARATIVE CONFIGURATION!
[13:02:19 CDT(-0500)] <Bosmon> I am dealing with making a "global progress indicator" UI for CollectionSpace
[13:02:33 CDT(-0500)] <Bosmon> So... as each AJAX call is serviced, the layout in the DOM may shift about a little bit....
[13:03:04 CDT(-0500)] <athena> cool
[13:03:20 CDT(-0500)] <Bosmon> Which means that the "blocking UI" might need to be layed out again
[13:04:43 CDT(-0500)] <Bosmon> But given we "planned all our AJAX calls up front" by laying them out in a declarative "resourceSpecs" structure, we can easily supply interception for ALL of them...
[13:05:02 CDT(-0500)] <athena> sounds nice
[13:05:14 CDT(-0500)] <Bosmon> I wonder if John Lewis is still hanging out with the fruity AspectJ pals over the SpringSource fence?
[13:05:36 CDT(-0500)] <athena> you know i'm not really sure what he's doing w/ spring these days
[13:05:45 CDT(-0500)] <athena> i suspect we keep him pretty busy
[13:10:02 CDT(-0500)] <athena> restarting . . .
[13:11:40 CDT(-0500)] <golam> colinclark: I have tested progress with ORCA screen reader and it's reading from the label. In all cases such as aria-live, aria-valuetext, and aira-valuenow it's reading from the label and saying "10% complete". I am going to test with Jaw 11 and 12(beta) .I will keep you posted
[13:13:05 CDT(-0500)] <colinclark> golam: Sounds good. So, in other words, Orca's working great?
[13:14:16 CDT(-0500)] <golam> that's right
[13:15:19 CDT(-0500)] <colinclark> Cool
[13:41:55 CDT(-0500)] <justin_o> Bosmon: looking at inline edit with mlam
[13:42:42 CDT(-0500)] <justin_o> we've started by changing the default action of bindblurhandler to use deadmansblur if no other function is passed in to the defaults...
[13:44:04 CDT(-0500)] <justin_o> we were thinking of making the arguments of deadmansblur configurable by the user as well
[13:44:41 CDT(-0500)] <Bosmon> Yes, that was the point
[13:44:55 CDT(-0500)] <justin_o> okay good, we're on the right track this time
[13:45:01 CDT(-0500)] <Bosmon> Well, partially
[13:45:12 CDT(-0500)] <justin_o> okay... what part are we missing
[13:45:15 CDT(-0500)] <Bosmon> I don't think changing the default action is on the right track
[13:45:20 CDT(-0500)] <justin_o> oh okay
[13:45:36 CDT(-0500)] <Bosmon> Well... I guess if we are planning to make this the default configuration, perhaps it is
[13:46:03 CDT(-0500)] <Bosmon> But, the user has the option to configure the component with the button missing
[13:46:18 CDT(-0500)] <justin_o> what do you mean by that?
[13:46:36 CDT(-0500)] <Bosmon> Well, sometimes the "standard" blur handler is still correct
[13:46:40 CDT(-0500)] <justin_o> i think the idea now is to always have the button, visible or not
[13:46:46 CDT(-0500)] <Bosmon> I see
[13:47:08 CDT(-0500)] <Bosmon> I think the best route would be to have configuration for a set of "dead man's elements"
[13:47:18 CDT(-0500)] <Bosmon> If that is empty, the blur handler should use the historical method
[13:47:47 CDT(-0500)] <justin_o> okay... but would that break backwards compatability
[13:48:08 CDT(-0500)] <justin_o> oh i see.. we would still have the option to pass in a new function and an option for the configuration
[13:48:30 CDT(-0500)] <Bosmon> yes
[13:49:34 CDT(-0500)] <justin_o> okay... good.. this is sort of what we were doing, but we were trying to actually define the defaults in the defaults, which was a bit problematic..
[14:08:21 CDT(-0500)] <justin_o> Bosmon: we're noticing that the fluid.inlineEdit.dropdown use of fluid.deadmansblur uses references to values from teh that.. which we probably don't have access to pass in as defaults
[14:09:04 CDT(-0500)] <justin_o> so for example that.editField may not exist when the defaults are registered, as the inlineEdit may inject it
[14:09:33 CDT(-0500)] <Bosmon> That's correct
[14:11:20 CDT(-0500)] <justin_o> we were going to change the the dropdown's defaults from passing in a bindblurhandler function to just using the new default with options for the deadmansblur... but how can we get access to the editField
[14:11:32 CDT(-0500)] <justin_o> or do we just keep it the way it is
[14:19:12 CDT(-0500)] <Bosmon> Given you are working in trunk, this might be a case where it already makes sense to start using IoC
[14:19:39 CDT(-0500)] <justin_o> Bosmon: really.. sounds like fun
[14:19:54 CDT(-0500)]

<Bosmon> If you define the blurHandlerBinder in the "components" tranch, you can declaratively ask to fetch a reference during initDependents using a syntax like

Unknown macro: {inlineEdit}

.editField

[14:20:34 CDT(-0500)] <Bosmon> initDependents is typically called as the last action of a component creator function, once all top-level "manual" construction has resoled
[14:20:36 CDT(-0500)] <Bosmon> resolved
[14:20:46 CDT(-0500)] <Bosmon> So it is designed to deal with cases exactly like this one
[14:21:17 CDT(-0500)] <justin_o> what is "components" tranch?
[14:21:32 CDT(-0500)] <justin_o> and you mean the options to the deadmansblur?
[14:22:04 CDT(-0500)] <justin_o> or i see.. with IoC we can redefine what the blurHandlerBinder function is
[15:34:00 CDT(-0500)] <anastasiac> athena, jess tells me you two were chatting about documentation last week. I'm spearheading a push to update our docs, so I'd love to chat some time, to hear any suggestions you might have for improvements
[15:34:12 CDT(-0500)] <athena> oh fantastic

[15:34:22 CDT(-0500)] <athena> and i can probably get some other developers from unicon to chime in
[15:34:35 CDT(-0500)] <anastasiac> that would be great!
[15:35:04 CDT(-0500)] <athena> we've had a number of new UE people join us in the last few months, so some of them might have good input - i find it's often more helpful to know what people think who aren't already familiar with a framework
[15:35:17 CDT(-0500)] <athena> i think the biggest feedback item we've heard is that the renderer is confusing
[15:35:18 CDT(-0500)] <anastasiac> agreed!
[15:35:29 CDT(-0500)] <athena> yeah, i think you already know that

[15:35:35 CDT(-0500)] <anastasiac> ah, wonderful things are in the pipe for simplifying renderer use!
[15:35:40 CDT(-0500)] <anastasiac> I'm wondering what might be a good way to go about this... skype conference?
[15:35:46 CDT(-0500)] <anastasiac> email exchanges?
[15:35:50 CDT(-0500)] <athena> one thing i've discovered lately too is that the "locate" method seems consistently misunderstood
[15:36:04 CDT(-0500)] <anastasiac> interesting
[15:36:23 CDT(-0500)] <athena> good question - email might be a good place to start, but i think it'd be useful to get together a skype call if we can fit schedules together
[15:36:42 CDT(-0500)] <anastasiac> I do want to provide more structure for the docs... to highlight the really more-commonly-used stuff quite clearly
[15:36:50 CDT(-0500)] <anastasiac> so it doesn't get lost
[15:36:58 CDT(-0500)] <athena> yeah - i think maybe even some sort of page that lists and explains common terms?
[15:37:21 CDT(-0500)] <anastasiac> we do have a start at that, but I think it's more of a glossary
[15:37:35 CDT(-0500)] <athena> i've seen a lot of attempts to pass the whole that.options.selectors.name into the locate method, or attempts to scope it to the container
[15:37:40 CDT(-0500)] <athena> neither of which of course are required
[15:37:47 CDT(-0500)] <anastasiac> but yes, hearing from people who are new to the code about what they're looking for, and how they'd expect to find it, woudl be great
[15:37:51 CDT(-0500)] <athena> people seem pleasantly surprised when they discover how its really used
[15:38:02 CDT(-0500)] <athena> i suspect a simple explanation of the event system would be really useful too
[15:38:09 CDT(-0500)] <anastasiac> ok, I'm adding that to my todo list: clarify how to use that.locate()
[15:38:21 CDT(-0500)] <anastasiac> yes, I think our events docs are a bit out of date
[15:40:02 CDT(-0500)] <anastasiac> athena, would the new UE people you're thinking of be on the fluid-work list? If I were to use that channel to solicit feedback and arrange a call, would they see it?
[15:40:15 CDT(-0500)] <athena> probably not, but i can track them down
[15:40:27 CDT(-0500)] <athena> and actually i'm flying out to phx this weekend, so i'll finally get to meet some of them in person
[15:40:35 CDT(-0500)] <anastasiac> cool!
[15:40:47 CDT(-0500)] <athena> yeah

[15:41:01 CDT(-0500)] <anastasiac> it's always great to finally meet in person people you've been working with for a while
[15:41:44 CDT(-0500)] <athena> definitely
[15:42:14 CDT(-0500)] <athena> let me ping matt - i know he's had some thoughts about documentation, and he of course knows all the UE developers much better than i do
[15:42:39 CDT(-0500)] <anastasiac> great, thanks
[15:42:45 CDT(-0500)] <athena> will do

[15:44:55 CDT(-0500)] <athena> documentation is hard
[15:45:02 CDT(-0500)] <anastasiac> indeed!
[15:45:06 CDT(-0500)] <athena> i'm glad we finally got a volunteer in the up community to help
[15:45:26 CDT(-0500)] <athena> i think it's making a difference
[15:46:10 CDT(-0500)] <athena> by the way, have any of you guys played w/ the jquery 1.4 etag support?
[15:48:26 CDT(-0500)] <anastasiac> athena, no, I haven't looked into that
[15:48:42 CDT(-0500)] <athena> ok
[15:48:46 CDT(-0500)] <athena> getting some weird behavior
[15:48:57 CDT(-0500)] <athena> would be really nice to have all our ajax calls support etags though
[15:53:40 CDT(-0500)] <Bosmon> aehtna - can you explain the kinds of misundersstandings people have?
[15:53:50 CDT(-0500)] <Bosmon> I am interested in how to misunderstand the locate() method

[15:54:33 CDT(-0500)] <athena> i've definitely seen people not realize the locate method scopes the search to the container
[15:54:49 CDT(-0500)] <athena> and also seen code that doesn't make use of the fact that the selector names are magicky
[15:55:06 CDT(-0500)] <athena> so wind up with that.locate(that.options.selectors.name) instead of that.locate("name")
[15:56:23 CDT(-0500)] <athena> though i know it does explain that in http://wiki.fluidproject.org/display/fluid/How+to+create+a+Fluid+Component
[15:56:31 CDT(-0500)] <athena> (which in my opinion is one of hte most useful pages in the wiki)
[15:56:39 CDT(-0500)] <athena> i like clear examples
[15:58:22 CDT(-0500)] <jessm> anastasiac: ^
[15:58:27 CDT(-0500)] <jessm> athena: good stuff to know!
[15:59:19 CDT(-0500)] <Bosmon> Oh I see
[15:59:32 CDT(-0500)] <Bosmon> That's very interesting
[15:59:32 CDT(-0500)] <athena> sadly i'm not sure i have a ton of great recommendations on how to organize things though - if i did, the uportal documentation would have been better before now

[16:00:00 CDT(-0500)] <anastasiac> athena, any and all thoughts are appreciated
[16:00:20 CDT(-0500)] <athena> on the whole though, my suggestion is that there's probably a need for some practical, specific, but not overly technical documentation of core fluid concepts
[16:00:54 CDT(-0500)] <athena> like explaining how the renderer works without explaining all of the underlying binding, what a bolus fossil whatever thing is, etc.
[16:01:11 CDT(-0500)] <athena> though that more detailed level does come in very useful when we're trying to do something complex
[16:01:21 CDT(-0500)] <anastasiac> yes, athena, that's one of the priorities we've identified. We want to produce more examples, with explanations to go with them
[16:01:28 CDT(-0500)] <athena> sounds great to me
[16:01:30 CDT(-0500)] <athena> i like examples
[16:01:39 CDT(-0500)] <athena> and i think the demo site you've created has actually been a huge help
[16:01:46 CDT(-0500)] <anastasiac> with more of a focus on how to use things - what to do to accomplish your goal (at least for the user docs)
[16:01:58 CDT(-0500)] <anastasiac> I'm glad to hear the demo site is useful!
[16:02:03 CDT(-0500)] <athena> perhaps more variations on those examples would be helpful as well - different configurations of components, using the renderer w/ the pager, etc.
[16:02:21 CDT(-0500)] <anastasiac> we're actually going to be redesigning it soon, too, so any thoughts on that will certainly be helpful
[16:02:31 CDT(-0500)] <athena> the demos?
[16:02:45 CDT(-0500)] <anastasiac> yes - we hope to produce more of them
[16:03:00 CDT(-0500)] <anastasiac> like what you've suggested above

[16:03:18 CDT(-0500)] <athena> sounds great

[16:03:19 CDT(-0500)] <athena> i'
[16:03:27 CDT(-0500)] <athena> i'll have to think of some things that are missing
[16:03:43 CDT(-0500)] <athena> though i have to admit it seems like we're constantly trying to do something really strange and complicated
[16:03:47 CDT(-0500)] <anastasiac> excellent
[16:04:00 CDT(-0500)] <anastasiac> and strange and complicated are our middle names!
[16:04:06 CDT(-0500)] <athena> really though the thing i love about working with you guys is that we can usually implement use cases you didn't originally anticipate
[16:04:08 CDT(-0500)] <athena> lol

[16:04:39 CDT(-0500)] <anastasiac> and we love to hear about those use cases - it's very hard to anticipate what your users are going to do with your stuff
[16:06:09 CDT(-0500)] <athena> yeah, flexibility really takes a lot of planning
[16:07:52 CDT(-0500)] <anastasiac> I have to run, athena, but thanks for your thought - keep them coming! I've started a thread on the infusion-users list - feel free to respond
[16:08:06 CDT(-0500)] <athena> will do! and i'll see if i can round up some uniconers
[16:08:09 CDT(-0500)] <athena> good to talk to you

Browser not supported