fluid-tech IRC Logs-2012-10-24

[13:52:28 CDT(-0500)] <Bosmon> yura and others may be interested in a private chatt I've just been having with colinclark about the new framework work - I pastied it here: http://pastie.org/5110699

[13:52:58 CDT(-0500)] <colinclark> Bosmon: yura and I were briefly chatting yesterday

[13:53:06 CDT(-0500)] <Bosmon> colinclark - great

[13:53:07 CDT(-0500)] <colinclark> at one point he looked a little exasperated

[13:53:15 CDT(-0500)] <colinclark> did you guys get a chance to check in

[13:53:20 CDT(-0500)] <Bosmon> Not yet

[13:53:27 CDT(-0500)] <colinclark> he mentioned to me a bug related to nicknames

[13:53:32 CDT(-0500)]

<Bosmon> I saw he had made a remark about not being able to get the name "

Unknown macro: {gpii.app}

" to resolve

[13:53:36 CDT(-0500)] <colinclark> which I didn't immediately understand the connection to

[13:53:38 CDT(-0500)] <colinclark> ah

[13:53:45 CDT(-0500)] <Bosmon> Which I'm not sure I can understand

[13:53:53 CDT(-0500)] <Bosmon> At least, without a test case (smile)

[13:53:55 CDT(-0500)] <colinclark> He pasted me a chat where you guys were talking about grades

[13:54:07 CDT(-0500)] <Bosmon> In general the use of nicknames should be limited to those cases where there is "polymorphism"

[13:54:13 CDT(-0500)] <Bosmon> For example, in the case of gpii.dataSource

[13:54:37 CDT(-0500)] <Bosmon> Nicknames are only necessary to compensate for the fact that right now we have only one "concrete name" allowable per component

[13:55:10 CDT(-0500)] <Bosmon> In the upcoming framework, all grade names and "demands rewrite names" will be available for resolution and this problem will go away

[13:56:05 CDT(-0500)] <yura> Bosmon: this is exactly what's needed

[13:56:16 CDT(-0500)] <Bosmon> yura - great

[13:56:20 CDT(-0500)] <Bosmon> Can you explain why?

[13:56:24 CDT(-0500)] <yura> well ok

[13:56:36 CDT(-0500)] <Bosmon> What is the REAL type of the component you are expecting to be a gpii.app

[13:56:40 CDT(-0500)] <yura> so i have a component gpii.app

[13:56:47 CDT(-0500)] <yura> and it is also used as a grade for

[13:56:52 CDT(-0500)] <yura> gpii.preferencesServer

[13:56:57 CDT(-0500)] <yura> that is also used as a grade for

[13:57:05 CDT(-0500)] <yura> gpii.preferencsServer.development

[13:57:18 CDT(-0500)] <yura> at this point

[13:57:32 CDT(-0500)] <yura> i can only resolve against gpii.preferencesServer

[13:57:34 CDT(-0500)] <yura> sorry

[13:57:42 CDT(-0500)] <yura> gpii.preferncesServer.development

[13:57:55 CDT(-0500)] <yura> and all the demands that i might have that have gpii.preferencesServer

[13:57:58 CDT(-0500)] <yura> are neglected

[13:58:24 CDT(-0500)] <yura> now lets say i want to write a demands block that wants to resolve gpii.app or app

[13:58:29 CDT(-0500)] <yura> so for every app

[13:58:41 CDT(-0500)] <yura> i would have to use the trick that we did in dataSource

[13:58:49 CDT(-0500)] <yura> where we assigned nickName ourselves

[13:59:01 CDT(-0500)] <yura> so lets say i can resolve both

[13:59:14 CDT(-0500)] <yura> app and gpii.preferencesServer.development

[13:59:20 CDT(-0500)] <yura> but it is still not enough

[13:59:43 CDT(-0500)] <yura> so that's why i m saying that resolution of all grade names is highly desirable

[13:59:49 CDT(-0500)] <yura> i mean it is only natural

[13:59:53 CDT(-0500)] <yura> it's like having additive demands

[14:00:07 CDT(-0500)] <yura> Bosmon: ^

[14:01:35 CDT(-0500)] <Bosmon> yura - ok, this all sounds quite reasonable

[14:01:54 CDT(-0500)] <Bosmon> That is, yes, you have correctly characterised the problem and deployed our best known solution to it : P

[14:02:09 CDT(-0500)] <Bosmon> You should make sure just for consistency that the nickname is "gpii.app" rather than just "app"

[14:02:17 CDT(-0500)] <Bosmon> So that when the framework is fixed, you don't need to change your demands blocks

[14:02:19 CDT(-0500)] <yura> yes i was thinking about it

[14:02:26 CDT(-0500)] <yura> thanks!

[14:04:26 CDT(-0500)] <yura> so Bosmon i pretty much settled on writing no demands that only override the funcName that would point to some final grade, but I still have an issue of not repeating myself in configs that are not specific to just 1 module

[14:04:48 CDT(-0500)] <Bosmon> yura - can you paste an example?

[14:04:50 CDT(-0500)] <yura> yes

[14:04:57 CDT(-0500)] <yura> Bosmon: here's a base config for pref server http://pastie.org/5110760

[14:05:18 CDT(-0500)] <yura> and a dev one http://pastie.org/5110763

[14:05:31 CDT(-0500)] <yura> so both are used if i run prefs server with default settings

[14:05:44 CDT(-0500)] <yura> so the block that is problematic is demands

[14:05:57 CDT(-0500)] <yura> since i cant convert 2 demands for the same demanding name to a single grade

[14:06:37 CDT(-0500)] <Bosmon> yura - which demands block are you referring to?

[14:07:05 CDT(-0500)] <yura> so the one in base

[14:07:11 CDT(-0500)] <yura> for request handler

[14:07:24 CDT(-0500)] <yura> i have 2 demands that resolve to handler's grade

[14:07:29 CDT(-0500)] <yura> in different contexts

[14:07:43 CDT(-0500)] <yura> if i were to have a higher level grade , how can it contain to cases?

[14:10:01 CDT(-0500)] <Bosmon> yura - where is the other demands?

[14:41:24 CDT(-0500)] <yura> Bosmon: (smile) i guess let me start over (smile)

[14:41:54 CDT(-0500)] <yura> Bosmon: so those 2 pasties are what constitutes all configuration for the preferences server

[14:42:31 CDT(-0500)] <yura> Bosmon: which means that when i want to deploy it along with the other component in the architecture

[14:42:53 CDT(-0500)] <yura> i need to wrap it as some sort of grade, was I interpreting your proposed solution correctly , Bosmon ?