fluid-work IRC Logs-2013-06-03

[09:08:05 CDT(-0500)] <colinclark> jhernandez: I have to say, it's so awesome that when we encounter a bug in Orca, you can just dive in and fix it.

[09:08:18 CDT(-0500)] <colinclark> Thanks for all your helps with this never-ending pilot process

[09:09:30 CDT(-0500)] <jhernandez> colinclark: heh

[09:09:33 CDT(-0500)] <jhernandez> yw

[09:09:55 CDT(-0500)] <colinclark> I'm looking forward to seeing you in person in a couple weeks, too.

[09:10:01 CDT(-0500)] <colinclark> I owe you a beer, or several

[09:10:27 CDT(-0500)] <jhernandez> heh

[09:10:32 CDT(-0500)] <jhernandez> me too

[09:10:46 CDT(-0500)] <jhernandez> I think we owe some beers to each other

[09:11:00 CDT(-0500)] <jhernandez>

[09:16:06 CDT(-0500)] <colinclark>

[09:18:29 CDT(-0500)] <colinclark> nanook: How's it going?

[09:19:49 CDT(-0500)] <nanook> colinclark: good! done with my visa stuff. reading up on fluid-infusion

[09:19:58 CDT(-0500)] <colinclark> nice!

[09:20:11 CDT(-0500)] <nanook> tomorrow's meeting is on I hope?

[09:20:30 CDT(-0500)] <colinclark> As you read through the documentation, if you find anything that's particularly helpful or confusing, I'm sure anastasiac will be keen to hear about it

[09:20:38 CDT(-0500)] <colinclark> nanook: Yep. did we settle on a time?

[09:22:27 CDT(-0500)] <nanook> colinclark: we decided on sometime in the morning (your time)

[09:23:12 CDT(-0500)] <colinclark> ok

[09:23:17 CDT(-0500)] <colinclark> let me have a look at the calendar

[09:23:20 CDT(-0500)] <colinclark> and we can pick a specific time

[09:28:52 CDT(-0500)] <colinclark> How about 11 am EDT, nanook?

[09:29:43 CDT(-0500)] <nanook> colinclark: works for me

[09:29:50 CDT(-0500)] <colinclark> excellent. I'll pencil it in

[10:22:14 CDT(-0500)] <Justin_o> anastasiac: i was just reading over http://wiki.fluidproject.org/display/fluid/Designing+a+new+UIO+API

[10:22:35 CDT(-0500)] <Justin_o> for the section "Using a subset of the included panels (no schema)"

[10:22:52 CDT(-0500)] <Justin_o> is the defaultSiteSettings option intentionally missing from the UIO options

[10:22:54 CDT(-0500)] <Justin_o> ?

[10:25:25 CDT(-0500)] <anastasiac> ah, good catch, Justin_o. I'm actually not sure, now that I think about it. I would have to double-check, but I believe that the "built-in" grade that includes all six panels defines the default settings for those panels, so a user-defined grade for two of the six would likely have to define the default settings for those two. Does that make sense, and does that seem like a reasonable API to you?

[10:28:50 CDT(-0500)] <Justin_o> anastasiac: yes.. that makes sense to me

[10:29:11 CDT(-0500)] <anastasiac> ok, Justin_o, I'll double-check how the existing grade works, and update the wiki page accordingly

[10:44:32 CDT(-0500)] <Justin_o> anastasiac: thanks.. i guess we will need to chat with antranig about the 4th party stuff..

[10:45:45 CDT(-0500)] <anastasiac> Justing_o, UIO and UIO get "defaultSiteSettings" from the setting store, which starts with the defaults for the "included" six panels. So even if an integrator is only using two of the panels, the defaults will already be there. So an integrator only needs to specify defaults for anything "new"

[10:49:18 CDT(-0500)] <Justin_o> anastasiac: what happens if a user was to change these, would it modify the store?

[10:49:19 CDT(-0500)] <anastasiac> Justin_o: ^ (and that should be "UIO and UIE)

[10:49:39 CDT(-0500)] <anastasiac> yes, Justin_o, it would

[10:50:43 CDT(-0500)] <Justin_o> anastasiac: okay.. thanks… so these defaults are fed back up to the store

[10:50:52 CDT(-0500)] <Justin_o> anastasiac: and the store is a sub component?

[10:51:18 CDT(-0500)] <anastasiac> Justin_o, I'm not sure the exact process, but I believe so

[10:51:43 CDT(-0500)] <Justin_o> anastasiac: okay.. thansk

[10:51:44 CDT(-0500)] <Justin_o> thanks

[11:17:32 CDT(-0500)] <Justin_o> anastasiac: just looking over things again.. so would you not need the defaultSiteSettings in the Page enhancer then

[11:18:29 CDT(-0500)] <anastasiac> Justin_o, good catch, that's a mistake

[13:49:54 CDT(-0500)] <cindyli> hi Bosmon2

[14:10:11 CDT(-0500)] <Bosmon2> Hi cindyli - there you are!

[14:10:19 CDT(-0500)] <Bosmon2> Thanks so much for the tests and JIRAs

[14:10:21 CDT(-0500)] <Bosmon2> They look great

[14:10:39 CDT(-0500)] <cindyli> cool. i hope they make sense

[14:11:24 CDT(-0500)] <Bosmon2> They look perfect - I'll start work on them very shortly

[14:11:35 CDT(-0500)] <cindyli> thanks, Bosmon2

[14:13:29 CDT(-0500)] <Justin_o> Bosmon2: i added some comments to the thread about the naming issues.. i'm not sure my comments were particularly helpful though… I'm available to chat about them here now if you like, i'll probably be heading out in about 15 minutes though

[14:24:33 CDT(-0500)] <anastasiac> cindyli, you worked a bit on the UIO internationalization, right?

[14:24:51 CDT(-0500)] <cindyli> yes, anastasiac

[14:25:14 CDT(-0500)]

[14:25:23 CDT(-0500)] <anastasiac> do you know what uioMsgBundle is referring to?

[14:25:38 CDT(-0500)] <cindyli> uioMsgBundle should be defined in i18n.js

[14:26:00 CDT(-0500)] <anastasiac> I'm working with a build of infusion. Did that file get added to the dependencies json file?

[14:26:12 CDT(-0500)] <cindyli> good point. checking

[14:26:33 CDT(-0500)] <cindyli> seems not. good catch. a jira for that

[14:32:20 CDT(-0500)] <anastasiac> cindyli: http://issues.fluidproject.org/browse/FLUID-5031

[14:32:48 CDT(-0500)] <cindyli> thanks, anastasiac

[15:35:19 CDT(-0500)] <colinclark> Hey Bosmon2, I had a nice chat this morning with Keith Hazelton from UW Madison

[15:35:19 CDT(-0500)] <colinclark> about authorization and privacy technologies

[15:35:40 CDT(-0500)] <colinclark> He outlined an approach that was quite consistent with some of the things we were discussing a month or so ago

[15:36:17 CDT(-0500)] <colinclark> in terms of starting by integrating the Preferences Server with OAuth 2.0

[15:36:27 CDT(-0500)] <colinclark> and then considering how User Managed Access might also play a role

[15:38:27 CDT(-0500)] <yzen> hi all,

[15:38:42 CDT(-0500)] <yzen> Bosmon2 and i were chatting about http://issues.fluidproject.org/browse/FLUID-5016

[15:39:05 CDT(-0500)] <yzen> he suggested to take declarative approach in expressing listeners for applier model changes

[15:39:50 CDT(-0500)] <Bosmon> colinclark - that seems interesting

[15:40:27 CDT(-0500)] <colinclark> yzen: Did you discuss what that declarative approach might look like yet?

[15:40:29 CDT(-0500)] <colinclark> I'm quite curious

[15:40:41 CDT(-0500)] <yzen> colinclark: yes something similar to a mergePolicy

[15:41:00 CDT(-0500)] <yzen> that would contain a key value pairs with the key being a path into a model and the value a listener

[15:41:02 CDT(-0500)] <colinclark> Do you have a gist or pastie or anything as an example?

[15:41:25 CDT(-0500)] <yzen> no not really, this was my initial stab at the non-declarative way https://github.com/yzen/infusion/commit/18d13ebdf5663395254abc95b7034912fd85e46a

[15:41:47 CDT(-0500)] <yzen> which something that's been done a number of times in a number of places

[15:41:53 CDT(-0500)] <colinclark> ah yes

[15:42:05 CDT(-0500)] <colinclark> It certainly would be cool to do something more declarative

[15:42:27 CDT(-0500)] <colinclark> Would I be wasting your time to ask you to sketch what you imagine this would look like in the declarative scheme?

[15:42:34 CDT(-0500)] <yzen> So i was going to ask Bosmon, how would a listener be expressed declaratively ?

[15:43:18 CDT(-0500)] <Bosmon> And my answer was going to be "just the way it looks in the listeners block in current eventedComponents"

[15:43:38 CDT(-0500)] <yzen> Bosmon: cool

[15:43:56 CDT(-0500)] <Bosmon> Only we will just have one extra level of path nesting, to express the paths tructure

[15:43:58 CDT(-0500)] <yzen> what about a case where listener is not attached at the time of component creation ?

[15:43:59 CDT(-0500)] <Bosmon> structure

[15:44:11 CDT(-0500)] <Bosmon> yzen - there are no such cases in a moral world

[15:44:24 CDT(-0500)] <yzen> Bosmon: i m not sure what world you live in

[15:44:26 CDT(-0500)] <colinclark> example, just so i'm clear?

[15:44:35 CDT(-0500)] <Bosmon> I live in a world where component creation is the only time there is

[15:44:42 CDT(-0500)] <Bosmon> Likewise, component destruction : P

[15:44:48 CDT(-0500)] <colinclark> until we get to "live coding"

[15:44:56 CDT(-0500)] <Bosmon> Even then!

[15:45:04 CDT(-0500)] <colinclark>

[15:45:17 CDT(-0500)] <colinclark> example me up, zenvich

[15:45:19 CDT(-0500)] <yzen> Bosmon: may I suggest that this is might not always be the case of how such grade would be used

[15:45:59 CDT(-0500)] <Bosmon> yzen - you may suggest it

[15:46:05 CDT(-0500)] <Bosmon> But it is not how we plan for the framework to function

[15:46:08 CDT(-0500)] <Bosmon> http://pastie.org/8002116

[15:46:43 CDT(-0500)] <yzen> are there other things than modelChanged, Bosmon ?

[15:46:52 CDT(-0500)] <Bosmon> We don't believe in a world where people call functions on things and apply "addListener/removeListener" any more than we did for standard events

[15:46:57 CDT(-0500)] <Bosmon> We also have "guards"

[15:47:02 CDT(-0500)] <Bosmon> And may perhaps also have other model-mapped events

[15:47:35 CDT(-0500)] <yzen> im just thinking of a way people use frameworks these days , they would create an object and then call bind or on or whatever on it

[15:47:54 CDT(-0500)] <Bosmon> Yes, but we are not building "frameworks" : P

[15:47:58 CDT(-0500)] <Bosmon> We are building our framework....

[15:48:20 CDT(-0500)] <Bosmon> And currently are trying as hard as possible to deprecate every function call in the framework that we can

[15:48:52 CDT(-0500)] <Bosmon> So it looks like the current model-mapped events that we support are "guards", "postGuards", and "modelChanged"

[15:49:05 CDT(-0500)] <Bosmon> And clearly we would like to make it easy for people to define and use new ones

[15:49:43 CDT(-0500)] <yzen> Bosmon: i see what you are saying

[15:50:31 CDT(-0500)] <yzen> but it will be 2ce the effort since we would need to state very clearly how to use our framework, which again implies a slightly higher barrier

[15:50:43 CDT(-0500)] <Bosmon> yzen - we are committed to this effort in any case

[15:50:54 CDT(-0500)] <Bosmon> Unless we state very clearly how to use our framework, noone will use it anyway

[15:51:52 CDT(-0500)] <Bosmon> And I'm not convinced that the barrier to declaring a new block of declarative configuration that works just how all our existing events work is any higher barrier than explaining to people that "model-based events are special, you need to use this special grade which has some binding methods you can call"

[15:52:22 CDT(-0500)] <Bosmon> After all, they can still use applier.addListener should they want things to call methods on

[15:52:32 CDT(-0500)] <Bosmon> Even though we will discourage them

[15:52:59 CDT(-0500)] <yzen> why would this stuff not be part of the modelComponent grade then ?

[15:53:16 CDT(-0500)] <Bosmon> It will be

[15:53:23 CDT(-0500)] <yzen> should i make it so

[15:53:23 CDT(-0500)] <yzen> ?

[15:53:31 CDT(-0500)] <Bosmon> I imagine we will give it a trial to start with by putting it in a separate grade

[15:53:34 CDT(-0500)] <yzen> in my branch ?

[15:53:35 CDT(-0500)] <Bosmon> Until it is fully baked

[15:53:36 CDT(-0500)] <yzen> ok

[15:53:54 CDT(-0500)] <Bosmon> Well, it can go into the main framework in a separate grade until we are convinced it is complete

[15:53:56 CDT(-0500)] <yzen> http://media.tumblr.com/tumblr_ma32oayImg1qkj7vc.jpg

[15:54:01 CDT(-0500)] <Bosmon> Similar to the way we have the "provisional" model relay systems

[15:54:07 CDT(-0500)] <Bosmon> Neither of the two of those are ready yet

[15:54:20 CDT(-0500)] <Bosmon> So they are still sitting out in the component world

[15:54:54 CDT(-0500)] <Bosmon> yura - cool - glad to see your enthusiasm for implementing this incredibly strategic part of the framework

[15:56:14 CDT(-0500)] <yzen>