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 " " 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
[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: i guess let me start over
[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 ?