[16:34:58 CDT(-0500)] <travis_84> Hey Bosmon
[16:35:29 CDT(-0500)] <Bosmon> Hey there travis_84!
[16:35:33 CDT(-0500)] <Bosmon> How's it going?
[16:35:41 CDT(-0500)] <Bosmon> Looking forward to the next check-in 
[16:35:58 CDT(-0500)] <travis_84> just checking in to give an update...
[16:36:27 CDT(-0500)] <travis_84> good actually
[16:36:35 CDT(-0500)] <Bosmon> Super
[16:37:44 CDT(-0500)] <travis_84> updated the github last night w/ a working voice-capture and server-result
[16:38:31 CDT(-0500)] <Bosmon> That's great, I'll take a look
[16:38:39 CDT(-0500)] <Bosmon> What are the current challenges?
[16:40:06 CDT(-0500)] <travis_84> just understanding how to work w/ JSON-to-JSGF or vice versa
[16:40:26 CDT(-0500)] <travis_84> here is the docs for WAMI http://wami.csail.mit.edu/documentation.html
[16:42:00 CDT(-0500)] <travis_84> I have literally gone through it a dozen times trying to create an effect strategy for how to make a command/response
[16:45:05 CDT(-0500)] <travis_84> so far all i have it do is send the results to a div id="live" role="log" aria-live="polite" aria-atomic="true" aria-relevant="additions"
[16:50:46 CDT(-0500)] <Bosmon> Ok - that seems like a reasonable strategy
[16:51:02 CDT(-0500)] <Bosmon> Want to talk in more detail about the JSON angle?
[16:51:13 CDT(-0500)] <Bosmon> Have you drawn up a "basic command set" of things you need to be able to recognise?
[16:51:33 CDT(-0500)] <Bosmon> Probably the easiest thing would be to work from the app end, and figure out how to encode everything you need to accept in ANY kind of JSON
[16:51:48 CDT(-0500)] <Bosmon> And then deal with the JSON-to-JSGF step as a completely separate process
[16:52:21 CDT(-0500)] <Bosmon> If you do run into anything that makes life hard, you could go back and tweak the JSON, but really, converting JSON structures into "other things" is generally a pretty tractable and flexible process
[16:54:12 CDT(-0500)] <travis_84> all results are sent back in JSON and they have a sort-of simple explanation of how to deal with the results
[16:55:28 CDT(-0500)] <travis_84> I am writing up a basic starter command set as an initial starter
[16:55:55 CDT(-0500)] <travis_84> right now I am dealing w/ the JSGF mess
[16:56:18 CDT(-0500)] <travis_84> I hated Java...
[16:57:37 CDT(-0500)] <travis_84> also can you tell me why a jQuery .empty() would fire before a .delay()?
[17:10:45 CDT(-0500)] <Bosmon> ?
[17:10:57 CDT(-0500)] <Bosmon> Neither of them are events... so I'm not sure "firing" is the right model
[17:11:10 CDT(-0500)] <Bosmon> Certainly empty is a piece of DOM manipulation which executes immediately
[17:11:31 CDT(-0500)] <Bosmon> And the whole purpose of "delay" is to executing things later...
[17:11:48 CDT(-0500)] <Bosmon> So it's not unreasonable to find one happening before the other
[17:11:55 CDT(-0500)] <Bosmon> What effect are you trying to achieve, specifically?
[17:14:27 CDT(-0500)] <travis_84> live.append('<p>' + (result.text()) + '</p>').addClass('success').slideDown(300).delay(2000).slideUp(300).empty(); adds the class and slides right but appends empty
[17:15:48 CDT(-0500)] <Bosmon> Yes
[17:15:53 CDT(-0500)] <Bosmon> All of that stack executes synchronously
[17:16:31 CDT(-0500)] <travis_84> for now I have .empty() first then the rest
[17:16:59 CDT(-0500)] <Bosmon> "Only subsequent events in a queue are delayed; for example this will not delay the no-arguments forms of .show() or .hide() which do not use the effects queue."
[17:17:18 CDT(-0500)] <Bosmon> You can't stop the evaluation of the entire jQuery function chain immediately
[17:17:37 CDT(-0500)] <travis_84> ahh
[17:17:37 CDT(-0500)] <Bosmon> And since "empty" is not an event, it finishes immediately upon evaluation
[17:18:15 CDT(-0500)] <Bosmon> The docs there recommend that you employ setTimeout if you truly want to defer some effect asynchronously
[17:18:17 CDT(-0500)] <Bosmon> Which I recommend
[17:19:44 CDT(-0500)] <travis_84> so setTimeout can help me empty and remove class after slideUp?