fluid-work IRC Logs-2011-08-16

[10:32:43 CDT(-0500)] <heidi_> stand up?
[12:46:14 CDT(-0500)] <huslage> where colinclark be?
[13:33:55 CDT(-0500)] <Bosmon> Hi Justin_o - what's the news today?
[13:34:17 CDT(-0500)] <Justin_o> Bosmon: hello
[13:36:16 CDT(-0500)] <Justin_o> Bosmon: i provided anastasiac with some feed back on her pull request to fix up the repo. We've all been working on the Masters program stuff pretty much all day so far, so I doubt she's had a chance to look at it yet
[13:36:40 CDT(-0500)] <Justin_o> Bosmon: michelle is waiting on a code review for her parser work, but colinclark might be doing that
[13:37:49 CDT(-0500)] <Bosmon> Justin_o - ok
[13:38:07 CDT(-0500)] <Bosmon> I tried to work on Kettle last night but quickly found it is pretty much impossible without additive demands blocks
[13:38:11 CDT(-0500)] <Bosmon> So I will turn to that for a while
[13:38:25 CDT(-0500)] <Bosmon> We have at least 3 pieces of work that are blocked on that now, so it is becoming quite strategic
[13:38:58 CDT(-0500)] <Justin_o> Bosmon: okay.. i take it that it is a requirement for 1.5
[13:39:18 CDT(-0500)] <Bosmon> Well, whatever we mean by 1.5 (tongue)
[13:39:40 CDT(-0500)] <Bosmon> But right now, we need it for CSpace, for Kettle and also to fix lahabana's work... and who knows what other things
[13:39:40 CDT(-0500)] <Justin_o> Bosmon: (smile) okay.. i guess that is a bit up in the air
[13:39:52 CDT(-0500)] <Justin_o> Bosmon: okay
[13:43:12 CDT(-0500)] <Bosmon> I think the most sensible way to implement Kettle will be in terms of "proleptic event binding" too...
[13:43:23 CDT(-0500)] <Bosmon> Which I guess is really in some sense the same kind of thing as "Luke Skywalker Options" (tongue)
[13:43:48 CDT(-0500)] <Bosmon> Right now UIOptions impl is such a complete mess because of the absence of this
[13:44:03 CDT(-0500)] <Bosmon> Probably 50% of the code is just there to juggle the fact of binding events onto things which may or may not exist yet
[13:45:28 CDT(-0500)] <Bosmon> We have events, listening to other events... in order to bind listeners onto other events
[13:45:36 CDT(-0500)] <Bosmon> This is "just the kind of thing we don't want" (tongue)
[13:48:55 CDT(-0500)] <anastasiac> Justin_o, I've pushed the changes and commented on the pull request for the new UIO demo (https://github.com/fluid-project/infusion/pull/138) so it's ready for another review
[14:28:40 CDT(-0500)] <anastasiac> cindyli, regarding the defaultSiteSettings for UI Options: Could you have a look at https://github.com/acheetham/Infusion-Instructional-Demos/blob/master/src/webapp/demos/instructional/uiOptions/html/fullNoPreview-customDefaultSiteSettings.html#L62L66 and check if this is the right way to set that option, or is there a simpler way?
[14:30:17 CDT(-0500)] <cindyli> anastasiac: thanks for trying it out. the simple way is http://pastie.org/2382152
[14:31:46 CDT(-0500)] <cindyli> anastasiac: note that remove all the cookies before seeing "defaultSiteSettings" in action because the site settings that are saved in the cookie always have higher priority at enhancer instantiation.
[14:31:53 CDT(-0500)] <Justin_o> anastasiac: thanks
[14:32:28 CDT(-0500)] <cindyli> This ntoes should be documented i think
[14:32:43 CDT(-0500)] <anastasiac> cindyli, interesting! yes, I agree it should definitely be documented!!
[14:37:00 CDT(-0500)] <anastasiac> cindyli, the store is pluggable, and the default store is the cookiestore. It doesn't look like the cookiestore has an api for clearing cookies. Does this mean the integrator has to write a script to clear cookies, or is there an easy way to do it using the existing cookiestore code?
[14:38:08 CDT(-0500)] <Bosmon> Should we perhaps munge this option after all?
[14:38:24 CDT(-0500)] <Bosmon> What do we think about how easy it is to configure the defaultSiteSettings
[14:39:21 CDT(-0500)] <cindyli> Bosmon: "defaultSiteSettings" is sort of munged already, it's available as a top level option.
[14:39:49 CDT(-0500)] <cindyli> anastasiac's question i think is what's the easy way to clean up the old saved cookie values
[14:39:55 CDT(-0500)] <anastasiac> Bosmon,, setting the default is easy, cindyli's pastie shows this. It's the resetting the cookies that should likely have an API, I think - as an integrator
[14:43:14 CDT(-0500)] <cindyli> anastasiac: i agree. what i'm doing now to clean up the cookie is to use the browser cookie list searching for "fluid-ui-settings" and remove it
[14:43:47 CDT(-0500)] <cindyli> not a pretty way tho (tongue)
[14:44:04 CDT(-0500)] <anastasiac> thanks for the pointer, cindyli - I'll use that for now, but I think it makes sense for any "store" api to include a way to clear the store if that's going to be necessary
[14:45:02 CDT(-0500)] <cindyli> agree
[14:50:25 CDT(-0500)] <Bosmon> 鼎!
[14:52:27 CDT(-0500)] <colinclark> what did you say, Bosmon?
[14:54:24 CDT(-0500)] <Bosmon> I was supporting the previous remark (tongue)
[15:10:31 CDT(-0500)] <anastasiac> cindyli, do you think the following would successfully clear the cookie in preparation for new defaults? fluid.cookieStore.save({}, fluid.defaults("fluid.cookieStore").cookie);
[15:12:28 CDT(-0500)] <Bosmon> anastasiac - I think it's more likely to corrupt the store
[15:12:29 CDT(-0500)] <cindyli> let me find out what is the default for ("fluid.cookieStore").cookie
[15:12:38 CDT(-0500)] <Bosmon> UIO gets very cranky if it doesn't find the default options it is expecting
[15:12:52 CDT(-0500)] <Bosmon> And if you look at the "fetch" implementation, on the last line if it finds any value in the store at all, it will return it
[15:13:10 CDT(-0500)] <Bosmon> It would be much superior to implement a dedicated "clear" method
[15:15:20 CDT(-0500)] <anastasiac> so if I visit site A (say, the BBC website) and pick a high contrast theme, then navigate to the New York TImes website, would I want my choice of high contrast to persist, or would I want my prefs to be site-specific?
[15:16:09 CDT(-0500)] <Bosmon> Well, you might, but I think that is an issue that is out of scope for the release
[15:16:22 CDT(-0500)] <Bosmon> If people want to address issues of this kind, they would have to implement their own kind of store
[15:19:08 CDT(-0500)] <anastasiac> Bosmon, sounds good. I'm just musing over different things.
[15:21:47 CDT(-0500)] <Bosmon> That's a sample of the kind of issue we will be addressing with the GPII-type "profile and preferences server" over the next few months
[15:30:15 CDT(-0500)] <colinclark> huslage, jhung: hey
[15:30:18 CDT(-0500)] <colinclark> ooh
[15:30:19 CDT(-0500)] <huslage> hey
[15:30:21 CDT(-0500)] <colinclark> bad timing (smile)
[15:30:27 CDT(-0500)] <colinclark> we lost jhung
[15:30:45 CDT(-0500)] <huslage> lol
[15:30:46 CDT(-0500)] <colinclark> okay, tomorrow morning i'll hook you guys up on Decapod install packages
[15:30:50 CDT(-0500)] <huslage> k
[15:32:01 CDT(-0500)] <colinclark> anastasiac: In the medium term, Bosmon is working on a new preferences server, built in Node.js, allowing for cross-site preferences. Some day, it will be great.
[15:32:08 CDT(-0500)] <colinclark> We have a roughly six month timeframe on that server
[18:53:36 CDT(-0500)] <Bosmon> HAIL HUSLAGE
[18:53:43 CDT(-0500)] <huslage> hail Bosmon