[08:06:59 CST(-0600)] <Justin_o> jhung: a while back you e-mailed the work list about a keyboard trap for rich text inline edit... did you file a jira for that as well?
[09:17:41 CST(-0600)] <jhung> justin_o: sorry I didn't hear your message come through.
[09:18:00 CST(-0600)] <jhung> justin_o: I didn't file a Jira for that keyboard trap bug. I can do that now.
[09:19:14 CST(-0600)] <Justin_o> jhung: if you don't mind, i responded to your e-mail after testing it with the latest nvda
[09:19:37 CST(-0600)] <jhung> justin_o: I saw. I'll include those findings in the Jira.
[09:20:51 CST(-0600)] <Justin_o> jhung: thanks
[09:21:54 CST(-0600)] <jhung> justin_o: Does the problem appear on Mac w FF3.6?
[09:24:37 CST(-0600)] <Justin_o> jhung: good point... since i could reproduce without nvda... i'll give it a try
[09:25:35 CST(-0600)] <Justin_o> jhung: yes.. i can reproduce that on Mac OS 10.6 with FF3.6
[09:26:25 CST(-0600)] <jhung> justin_o: Okay. I'll put this in. Should I mark it as a critical bug for this bug parade?
[09:27:03 CST(-0600)] <Justin_o> jhung: i'm not sure... richtext inline edit is still in sneak peek and may have something to do with tiny mce.. maybe i'll go test their site out now
[09:27:52 CST(-0600)] <jhung> justin_o: okay. I'll leave it as Major and leave it out of bug parade for now.
[09:28:36 CST(-0600)] <Justin_o> jhung: okay
[09:28:46 CST(-0600)] <Justin_o> jhung: here's there page, http://tinymce.moxiecode.com/examples/full.php#
[09:28:47 CST(-0600)] <Justin_o> i
[09:28:52 CST(-0600)] <Justin_o> it does seem to be working {color}
[09:29:07 CST(-0600)] <mlam> colinclark: did you want to meet to talk about the uploader's next steps?
[09:29:27 CST(-0600)] <Justin_o> jhung: hmm... actually it is working on ours too.. if you hold down the tab key you will eventually get out
[09:29:36 CST(-0600)] <Justin_o> i tried that on the mac
[09:29:44 CST(-0600)] <Justin_o> can you see if that works for you too
[09:29:56 CST(-0600)] <Justin_o> the bug may actualy just be a styling issue...
[09:30:47 CST(-0600)] <jhung> justin_o: I can tab through properly on the Tinymce site.
[09:31:46 CST(-0600)] <jhung> justin_o: http://issues.fluidproject.org/browse/FLUID-3865
[09:32:08 CST(-0600)] <colinclark> mlam: Gimme a bit to get oriented
[09:32:19 CST(-0600)] <colinclark> I think the next two big steps are quite clear for Uploader, though.
[09:32:21 CST(-0600)] <heidi_> hey justin_o , i'm just testing a patch for FLUID-3801 and then i'm hoping to switch to ui options - is that cool?
[09:32:24 CST(-0600)] <Justin_o> jhung: are you able to tab through ours if you hold down the tab key for a while
[09:32:24 CST(-0600)] <Justin_o> i was able to do this and could get out
[09:32:55 CST(-0600)] <Justin_o> heidi_: thanks... were you able to finish up with that other one you were looking at as well?
[09:33:08 CST(-0600)] <colinclark> 1. We should look into the XHR testing setup that Antranig recently added to jqUnit--I think it should allow us to write some fairly in-depth unit tests for Uploader
[09:33:21 CST(-0600)] <heidi_> justin_o FLUID-3635 ? i think i might pass it off to mike as a js thing
[09:33:24 CST(-0600)] <colinclark> 2. We need to wire up all the rest of Uploader's events
[09:33:41 CST(-0600)] <heidi_> justin_o i now don't think getting rid of inline-block solves that
[09:33:52 CST(-0600)] <colinclark> #2 will involve, firstly, the progress event. But then going through and making sure that we've got all the appropriate events firing at the right times, mlam
[09:34:50 CST(-0600)] <jhung> justin_o: ah. Yes. It works once you've tabbed through all the toolbar items.
[09:35:01 CST(-0600)] <mlam> Ok
[09:35:53 CST(-0600)] <colinclark> heidi_: The UI Options work is for Infusion 1.4, right?
[09:35:58 CST(-0600)] <heidi_> yep
[09:36:21 CST(-0600)] <colinclark> So I'm thinking that if there are still bugs to squash for 1.3 (which freezes soon!), we should do those first
[09:36:39 CST(-0600)] <colinclark> Justin_o: You should remind us of the deadlines for 1.3... I could use the extra bit of pressure
[09:36:41 CST(-0600)] <Justin_o> jhung: i wonder if you might want to update the jira about that.. i guess it's not really a keyboard trap as much as a styling bug with the focus missing
[09:37:24 CST(-0600)] <heidi_> colinclark , ah ok. justin_o ill take a look at the bug list and grab some more
[09:37:25 CST(-0600)] <Justin_o> colinclark: so December 9th is the last day to work on issues.
[09:37:47 CST(-0600)] <colinclark> ooh, so soon
[09:38:00 CST(-0600)] <Justin_o> I'd really like to wrap things up a day or so before that so we can spend Dec 9th working on the general issues like updating licenses, version numbers, dependencies, and etc.
[09:42:29 CST(-0600)] <colinclark> That makes sense
[09:42:39 CST(-0600)] <colinclark> There are a lot of those general tasks to do for this release
[09:44:24 CST(-0600)] <jhung> justin_o: updated.
[09:51:27 CST(-0600)] <heidi_> justin_o can take a look at some of the NVDA issues for inline edit
[09:51:48 CST(-0600)] <heidi_> and also FLUID-3860
[11:22:47 CST(-0600)] <colinclark> mlam: So there are more strategies for Uploading using HTML 5 than just two, it turns out
[11:22:55 CST(-0600)] <colinclark> Which is not altogether good news, but not a big deal
[11:23:18 CST(-0600)] <colinclark> Chrome doesn't implement File.getAsBinary()
[11:23:29 CST(-0600)] <colinclark> Looks like it has inherited Google Gears' old BlobBuilder API
[11:23:42 CST(-0600)] <colinclark> Which we already have code for
[11:23:45 CST(-0600)] <mlam> that's what I just read right now
[11:23:51 CST(-0600)] <mlam> weird coincidence.
[11:25:05 CST(-0600)] <mlam> should we just pull the Gears code out from the FLUID-1673 branch?
[11:25:50 CST(-0600)] <colinclark> Well, what we've got is close to that Gears code
[11:26:26 CST(-0600)] <colinclark> So we'll want to parameterize it-in other words, keep the "multipart request building" stuff generic-and then create implementations for BlobBuilder and getAsBinary
[11:26:39 CST(-0600)] <colinclark> I think I can whip something up fairly quickly while you move on with other stuff
[11:26:48 CST(-0600)] <mlam> ah i c
[11:26:48 CST(-0600)] <mlam> ok
[11:31:43 CST(-0600)] <colinclark> Interestingly, mlam, it looks like the latest Chrome supports FormData
[11:31:46 CST(-0600)] <colinclark> same with Safari, I think
[11:31:50 CST(-0600)] <colinclark> I'll play around
[11:35:07 CST(-0600)] <mlam> ugh. the browser detection code could look pretty ugly with all these browser exceptions
[11:35:18 CST(-0600)] <colinclark> It should be okay
[11:35:30 CST(-0600)] <colinclark> Mostly you do a series of checks to see if certain features exist
[11:35:37 CST(-0600)] <mlam> right
[11:35:47 CST(-0600)] <colinclark> we'll use IoC to do the feature checks and then drop a new context into the equation, causing the right implementation to just appear
[11:36:02 CST(-0600)] <colinclark> So, my copy of Chrome seems to work fine with the FormData approach
[11:36:12 CST(-0600)] <colinclark> I guess Chrome is a funny browser--it automatically updates itself, right?
[11:36:24 CST(-0600)] <colinclark> So, in a sense, there must be very few users who are actually running old versions of it
[11:37:03 CST(-0600)] <colinclark> mlam: Safari 5 is cool for FormData support, too
[11:37:30 CST(-0600)] <mlam> yes, it does
[11:37:51 CST(-0600)] <mlam> interesting....i wonder why FF didn't support formdata in 3.6
[11:41:02 CST(-0600)] <jhung> anastasiac: do you feel confident that the standalone demos for the kayboard a11y plugin can be removed / moved / consolidated?
[11:41:40 CST(-0600)] <anastasiac> jhung, right, thanks for reminding me - I was supposed to clean up the old tabs demos...
[11:42:14 CST(-0600)] <jhung> anastasiac: you were? in that case it's http://issues.fluidproject.org/browse/FLUID-3731.
[11:42:24 CST(-0600)] <anastasiac> yes, that's the one
[11:42:36 CST(-0600)] <jhung> It was assigned to me, but you can take it if you want.
[11:43:10 CST(-0600)] <anastasiac> jhung, go ahead - it doesn't matter who does it
[11:43:30 CST(-0600)] <anastasiac> I think we decided to remove the old tabs demos
[11:44:51 CST(-0600)] <jhung> anastasiac: okay. So that includes 2 demos I know of: the keyboard a11y and the reorderer tabs stand alone demos.
[11:45:21 CST(-0600)] * anastasiac is reviewing what's in SVN
[11:46:29 CST(-0600)] <anastasiac> jhung, the reorderer tabs stand alone demo... not sure about that one (looking now)
[11:47:07 CST(-0600)] <anastasiac> that's not a keyboard-a11y demo, that's a reorderer demo
[11:48:19 CST(-0600)] <anastasiac> there's this one, jhung: http://source.fluidproject.org/svn/scratchpad/tutorials/keyboard-a11y/ It should go
[11:48:54 CST(-0600)] <jhung> anastasiac: What about the keyboard a11y demo in stand-alone "jquery-ui-accessible-tabs.html"
[11:49:16 CST(-0600)] <anastasiac> oh, that one should definitely go - it doesn't even work!
[11:49:24 CST(-0600)] <anastasiac> jhung, I'm going to check my notes for when we reviewed the demos and decided what to do with them...
[11:49:29 CST(-0600)] <anastasiac> give me a minute or two
[12:15:15 CST(-0600)] <mlam> heidi_: the only outstanding issue with FLUID-3635 (can't edit empty inline edit) is if they set the default text in the options to be ""?
[12:40:59 CST(-0600)] <heidi_> mlam i think "" is fine, but if it's " " (a space) entered manually or via defaultviewtext , IE breaks
[12:41:14 CST(-0600)] <heidi_> the "" just looks weird, but it's still functional
[12:41:32 CST(-0600)] <mlam> i found a space works well in IE8, but the "" just doesn't work well, unless i inject some vertical padding
[12:41:38 CST(-0600)] <heidi_> the styling is a different jira... FLUID-3860
[12:42:07 CST(-0600)] <heidi_> if you enter a space, it doesn't break? for me i get a dotted line w/o pencil, not clickable
[12:42:15 CST(-0600)] <heidi_> but maybe i need to update if you've made recent changes
[12:42:27 CST(-0600)] <mlam> ohhh weird... my space is clickable
[12:42:49 CST(-0600)] <heidi_> ill dble check in a bit... my bro just showed up! gonna have lunch bbs
[12:42:58 CST(-0600)] <mlam> ok sounds good
[13:47:56 CST(-0600)] <Bosmon2> justin_o: Hail, O KINGGGG
[13:50:08 CST(-0600)] <justin_o> Bosmon2: hello
[13:50:59 CST(-0600)] <Bosmon2> I am unfortunately going to beg for your KINGGLY INDULGENCE once again
[13:53:53 CST(-0600)] <Bosmon2> I have just raised http://issues.fluidproject.org/browse/FLUID-3866
[13:54:16 CST(-0600)] <Bosmon2> Which is a work package that has elements which are usefully in common between the accessibility work we are doing, and a requirement for CSpace
[13:54:41 CST(-0600)] <Bosmon2> We really can't get much further with this approach of having each component locally maintaining a record of "strings" which are to be displayed just for itself
[13:54:53 CST(-0600)] <Bosmon2> I wonder if you might give this JIRA your KINGGLY eye
[13:55:25 CST(-0600)] <colinclark> Can you elaborate on the connection between this work and the accessibility sprint currently underway, Bosmon2?
[13:58:09 CST(-0600)] <Bosmon2> Yes - in my work on the Reorderer, it requires to "render" various relatively complex messages at certain points in the workflow
[13:58:31 CST(-0600)] <justin_o> Bosmon2: how is that coming along... will that be ready for 1.3
[13:58:46 CST(-0600)] <Bosmon2> it would be good to be able to configure Reorderers so that, for example, that they can inherit from some common configuration
[13:59:05 CST(-0600)] <Bosmon2> Also, it would be good to break the dependence on the renderer that this would ordinarily create
[13:59:27 CST(-0600)] <Bosmon2> As you may remember, we moved messageLocator and related things out of Fluid.js into FluidRenderer.js when we were on our "core framework purge" for Engage
[13:59:43 CST(-0600)] <Bosmon2> But I think it makes sense to move them back into the core framework, since they will be used by multiple core components
[14:00:17 CST(-0600)] <colinclark> Cool, that makes sense
[14:00:19 CST(-0600)] <colinclark> justin_o
[14:00:20 CST(-0600)] <Bosmon2> I think Reorderer should be ready yes - at least a resolution of the core JIRAs relating to notification of coordinates and motion
[14:00:25 CST(-0600)] <colinclark> justin_o's question seems timely
[14:00:37 CST(-0600)] <colinclark> Code freeze is Dec 9, as he mentioned this morning
[14:00:52 CST(-0600)] <colinclark> So, you feel good about that date for those "core JIRAs?"
[14:00:55 CST(-0600)] <colinclark> Bosmon2: ^
[14:01:07 CST(-0600)] <Bosmon2> Yes, that seems fine
[14:01:24 CST(-0600)] <Bosmon2> I just need to wrap up this bit of CSpace work that the message bundle depends on and then I can turn back to Reorderer
[14:02:23 CST(-0600)] <colinclark> So, the JIRA is a bit larger than just moving messageLocator and related things out of Fluid.js, no?
[14:02:32 CST(-0600)] <Bosmon2> Yes, there is new functionality
[14:02:33 CST(-0600)] <justin_o> Bosmon2: I think i'm not totally clear on what this new feature will provide
[14:02:39 CST(-0600)] <Bosmon2> But I have managed to implement it without changing any APIs
[14:03:02 CST(-0600)] <Bosmon2> I followed the approach we mentioned last night of leaving the existing "messageLocator" as a shell, and moving all the code into a new "proper component" called messageResolver
[14:03:35 CST(-0600)] <Bosmon2> justin_o: At the moment, all the message templates resolved by a component have to live in a single structure
[14:03:37 CST(-0600)] <Bosmon2> named "strings"
[14:03:45 CST(-0600)] <justin_o> yep
[14:04:25 CST(-0600)] <Bosmon2> So this is really not very scalable... even if we bring in "the whole structure" from somewhere else, it doesn't support the idea of sharing some values in common and not others
[14:04:43 CST(-0600)] <Bosmon2> In a proper "mature application" there will be default values for some messages, which an individual component might want to override
[14:04:57 CST(-0600)] <colinclark> Can you elaborate on a use case for such sharing, Bosmon2?
[14:05:00 CST(-0600)] <Bosmon2> For example, we might supply a default message bundle for "all Reorderers" which an individual reorderer might want different values for
[14:05:21 CST(-0600)] <Bosmon2> But they may not want to override ALL of the values, but just some of them
[14:05:46 CST(-0600)] <justin_o> Bosmon2: okay, but that could currently be done be means of our defaults?
[14:05:56 CST(-0600)] <colinclark> So, for example, the Image Reorderer might customize some of its messages to be specific to images instead of other types of elements
[14:06:21 CST(-0600)] <Bosmon2> justin_o: It could, but it would be very inefficient - and also, there is a risk with "heterogeneous templates"
[14:06:29 CST(-0600)] <Bosmon2> A message bundle isn't just a data structure....
[14:06:37 CST(-0600)] <Bosmon2> It is a data structure together with a strategy for resolving messages in it
[14:06:50 CST(-0600)] <Bosmon2> So, some bundles might use the "stringTemplate" format, and others might use the "java properties" format
[14:07:16 CST(-0600)] <Bosmon2> Unless there is dedicated code for managing this, a simple approach of merging the data structures won't create a successful collection
[14:07:26 CST(-0600)] <Bosmon2> Also... in a realistic application, the "default string bundle" might be VERY large
[14:07:41 CST(-0600)] <Bosmon2> It may contain many hundreds of messages.... we need ways of sharing this without requiring to duplicate it
[14:08:38 CST(-0600)] <Bosmon2> The use case in CSpace is fairly urgent... there are some messages, which are shared across essentially every component... or at least should be
[14:08:52 CST(-0600)] <Bosmon2> These contain the names of the basic record types, such as "Loan In", "Acquisition" etc.
[14:09:08 CST(-0600)] <Bosmon2> But in many cases, each component has its own local message bundle as well
[14:09:39 CST(-0600)] <justin_o> Bosmon2: okay... so this new approach would allow for both the stringTemplate and java properties format to be used, interchangeably? and also have a global (to fluid) strings block?
[14:09:48 CST(-0600)] <Bosmon2> justin_o: That's correct
[14:09:58 CST(-0600)] <Bosmon2> Not exactly "interchangeably" on the first point, but at least, simultaneously
[14:10:21 CST(-0600)] <Bosmon2> Clearly a component needs to know which format a particular message requires
[14:10:27 CST(-0600)] <Bosmon2> otherwise it can't prepare its argument list correctly
[14:10:49 CST(-0600)] <justin_o> yes... so is there some identifier associated with each string?
[14:10:49 CST(-0600)] <Bosmon2> That is, it needs to know whether arguments need to be prepared as an array, or as a hash
[14:11:28 CST(-0600)] <Bosmon2> Well, the API is functionally identical to the "messageLocator" API we already have
[14:11:31 CST(-0600)] <Bosmon2> It is just better factored
[14:11:42 CST(-0600)] <Bosmon2> And has a more flexible implementation
[14:13:32 CST(-0600)] <Bosmon2> We can perhaps deprecate "messageLocator" in this release and remove it in a subsequent one
[14:13:53 CST(-0600)] <justin_o> Bosmon2: okay.. and the global strings, how will those work
[14:20:31 CST(-0600)] <Bosmon2> Well, you can configure the "resolver" how you like
[14:20:53 CST(-0600)] <Bosmon2> It has an entry named "parents" which can register any number of other resolvers as parents which will be fallen back to if a message can't be found
[14:21:11 CST(-0600)] <justin_o> Bosmon2: what will this mean for the current strings block?
[14:23:02 CST(-0600)] <Bosmon2> It is supported as before
[14:23:22 CST(-0600)] <Bosmon2> "initRendererComponent" has been upgraded to detect what you have configured and support it appropriately
[14:23:51 CST(-0600)] <justin_o> so this will only work for graded renderer components?
[14:24:12 CST(-0600)] <justin_o> or i guess the autodetection will only work for that?
[14:25:17 CST(-0600)] <Bosmon2> Well, we have no grading right now
[14:25:20 CST(-0600)] <justin_o> Bosmon2: okay.. well it sounds reasonable... and you think it will help for the reorderer a11y work, and you'll have time to do it all...
[14:25:21 CST(-0600)] <justin_o> Bosmon2: okay
[14:25:23 CST(-0600)] <Bosmon2> You either call initRendererComponent or you don't
[14:25:34 CST(-0600)] <justin_o> manual grading
[14:25:42 CST(-0600)] <Bosmon2> Yes, well it's not even manual grading
[14:25:46 CST(-0600)] <Bosmon2> It is just the "grading of the mind"
[14:26:37 CST(-0600)] <colinclark> So, Bosmon2, I want to point out an interesting thing...
[14:27:14 CST(-0600)] <colinclark> You are, in many ways, mixing up features in Infusion required for general components (such as your current Reorderer a11y work), and others that are specific to CollectionSpace's own emerging needs
[14:27:36 CST(-0600)] <colinclark> In the midst of bug parade, I might well argue that we should be careful to separate these things
[14:28:07 CST(-0600)] <colinclark> So as to not risk increasing the likelihood of regressions or extra testing
[14:28:24 CST(-0600)] <colinclark> I think that Infusion 1.3 is probably a unique release in this regard
[14:28:26 CST(-0600)] <Bosmon2> ok
[14:28:36 CST(-0600)] <Bosmon2> I'm not sure how I could separate out the implementation to reflect that
[14:28:52 CST(-0600)] <colinclark> Well, I'm not talking about this specific case
[14:28:53 CST(-0600)] <Bosmon2> Unless we decide that the only thing we require for Reorderer work is messageLocator in core
[14:29:03 CST(-0600)] <Bosmon2> Which I am not really convinced of
[14:29:04 CST(-0600)] <Bosmon2> Ok
[14:29:13 CST(-0600)] <colinclark> 1.3 has been unique in that it's largely been a collection of fixes that have emerged over time...
[14:29:19 CST(-0600)] <Bosmon2> Well, the release is also "unique" in that we have "paraded" for over a month now
[14:29:43 CST(-0600)] <colinclark> Well, one could argue that these two issues might well be interconnected
[14:29:55 CST(-0600)] <colinclark> In some ways, you can think of this less as a planned release and more of a "it's time" release
[14:30:20 CST(-0600)] <colinclark> In that we built up a critical mass of features, had a few key things in the plan that we wanted to get done, and that's ultimately what makes up 1.3
[14:30:29 CST(-0600)] <colinclark> So, as I say, I'm not talking about specific issues here
[14:30:53 CST(-0600)] <colinclark> and I am arguing that Infusion 1.3 is well suited, as a release, to this kind of fairly measured expansion of parade issues
[14:31:12 CST(-0600)] <Bosmon2> ok
[14:31:13 CST(-0600)] <colinclark> I'm just thinking that this might not be always viable for our releases
[14:31:30 CST(-0600)] <colinclark> On the other hand, we may well increasingly find that our releases happen once that critical mass of features emerges
[14:31:35 CST(-0600)] <Bosmon2> You mean, an "expanding parade"?
[14:31:43 CST(-0600)] <colinclark> yes
[14:31:55 CST(-0600)] <colinclark> I'm just imagining myself in the King's shoes
[14:31:58 CST(-0600)] <colinclark> and they're big shoes
[14:32:05 CST(-0600)] <colinclark> sneakers, in his case
[14:32:08 CST(-0600)] <Bosmon2> hahaha
[14:32:12 CST(-0600)] <Bosmon2> Not sandals?
[14:32:34 CST(-0600)] <colinclark> And in some cases, I can imagine that he might be quite strict in trying to keep new features out of a release at the time of bug parade
[14:32:51 CST(-0600)] <colinclark> This is, I think, a case where that kind of strictness isn't necessary as much
[14:32:59 CST(-0600)] <colinclark> but we do want to be vigilant about two things:
[14:33:08 CST(-0600)] <colinclark> 1. Bug parade should be a time of increasing stability and awesomeness
[14:33:14 CST(-0600)] <colinclark> 2.
[14:33:17 CST(-0600)] <colinclark> I forget #2 already
[14:33:19 CST(-0600)] <colinclark> sheesh
[14:33:28 CST(-0600)] <colinclark> Ah
[14:33:44 CST(-0600)] <colinclark> 2. We don't want to have core features slip due to other new ones that weren't originally planned
[14:34:20 CST(-0600)] <colinclark> justin_o's decision gets substantially easier when we come to him and say "it's all done, and it has great unit tests, and I'm right on track for the other issues that are already on the bug parade"
[14:34:22 CST(-0600)] <Bosmon2> Right
[14:34:48 CST(-0600)] <colinclark> So I'm saying all this not because I think we need to do anything different or that your new i18n feature isn't worth putting into 1.3
[14:35:00 CST(-0600)] <colinclark> but I just I'm thinking aloud about what these sorts of decision mean in terms of the big picture
[14:35:06 CST(-0600)] <Bosmon2> Yes
[14:35:12 CST(-0600)] <colinclark> I think I'm done now
[14:35:32 CST(-0600)] <colinclark> justin_o: Do you ever wear sandals?
[14:35:43 CST(-0600)] <justin_o> colinclark: ah.. not if i can avoid it
[14:35:52 CST(-0600)] <colinclark> lol
[14:35:57 CST(-0600)] <colinclark> it's like me and shorts
[14:37:27 CST(-0600)] <justin_o> colinclark: but shorts are so comfortable
[14:37:34 CST(-0600)] <colinclark> So are sandals
[14:37:45 CST(-0600)] <justin_o> yes, but you can't play basketball in sandals
[14:38:17 CST(-0600)] <colinclark> You should see my friend Doug
[14:38:25 CST(-0600)] <colinclark> he has what he calls "dunking sandals"
[14:38:38 CST(-0600)] <colinclark> and fortunately hasn't had a broken ankle to go with them yet
[14:38:50 CST(-0600)] <justin_o> dunking sandals? well that's impressive...
[14:38:59 CST(-0600)] <justin_o> i'll have to come see this some time
[14:39:46 CST(-0600)] <colinclark> I think he's managed to buy some real basketball shoes now
[14:39:52 CST(-0600)] <colinclark> but you know, the life of a musician...
[14:39:58 CST(-0600)] <colinclark> hence dunking sandals
[14:41:37 CST(-0600)] <justin_o> okay
[14:43:31 CST(-0600)] <heidi_> soccer! i'm stoked
[14:52:01 CST(-0600)] <justin_o> heidi_: excellent... so you will be joining us then
[14:52:50 CST(-0600)] <heidi_> justin_o you bet. i haven't exercised in like 5yrs so hopefully i don't have a stroke or break a hip
[14:53:15 CST(-0600)] <justin_o> heidi_: lol i'm sure you'll be
[14:55:46 CST(-0600)] <justin_o> Bosmon2: added FLUID-3866 to bug parade
[14:55:56 CST(-0600)] <Bosmon2> Thanks, O KINGG
[15:04:50 CST(-0600)] <Bosmon2> Why does one dunk sandals?
[15:04:55 CST(-0600)] <Bosmon2> Is it to keep them from splitting?

Browser not supported