fluid-tech IRC Logs-2012-10-22
- Fluid IRC Log Bot
[12:41:00 CDT(-0500)] <yura> hi Bosmon2, so here's my older pull request, I updated some preferences server specific code/configuration to encode demands as json configuration, what do you think ?
[12:41:01 CDT(-0500)] <yura> https://github.com/GPII/universal/pull/55/files
[12:41:24 CDT(-0500)] <yura> it's at the bottom
[12:41:27 CDT(-0500)] <yura> last 5 files
[12:42:45 CDT(-0500)] <yura> I had to introduce an optional base config file that the loader will attempt to load for every configuration, it basically has some common configuration for any environment (type of deployement)
[12:42:51 CDT(-0500)] <yura> Bosmon2: ^
[12:47:53 CDT(-0500)] <Bosmon2> hi
[12:50:11 CDT(-0500)] <Bosmon2> I'm still not sure that the getOntologyName algorithm is correct
[12:50:16 CDT(-0500)] <Bosmon2> Did you consult those examples I pasted before?
[12:54:47 CDT(-0500)] <yura> for demands ? yes
[12:54:53 CDT(-0500)] <Bosmon2> For getOntologyName
[12:55:09 CDT(-0500)] <yura> you mentioned the approach yes, and i implemented it
[12:55:43 CDT(-0500)] <yura> your wrote : "It should in fact return the past segment following //gpii.org/ - and not the entire URL minus the final segment."
[12:55:50 CDT(-0500)] <Bosmon2> Yes
[12:55:56 CDT(-0500)] <Bosmon2> That doesn't appear to be what you implemented
[12:56:47 CDT(-0500)] <yura> Bosmon2: ok so if i ahve a key like that
[12:56:48 CDT(-0500)] <yura> "http://gpii.org/ontology/A4A-2.0/display/screenEnhancement/invertImages"
[12:57:16 CDT(-0500)] <yura> the ontology should be "ontology/A4A-2.0/display/screenEnhancement", no ? at least that's how I understood it
[12:57:22 CDT(-0500)] <Bosmon2> No, that's not correct
[12:57:28 CDT(-0500)] <Bosmon2> The ontology name should be "A4A-2.0"
[12:58:10 CDT(-0500)] <yura> hmm ok so the "display/screenEnhancement/invertImages" is a postfix ?
[12:58:11 CDT(-0500)] <Bosmon2> But having test cases which demonstrated this effect would remove all doubt 
[12:58:42 CDT(-0500)] <Bosmon2> The path "display/screenEnhancement/invertImages" is just the name of the preference/need, whatever...
[12:58:49 CDT(-0500)] <yura> right
[12:59:01 CDT(-0500)] <yura> well ok ill fix that algorithm
[12:59:11 CDT(-0500)] <Bosmon2> Which the ontology would probably transform into display.screenEnhancement.invertImages when it came to do anything with it
[12:59:31 CDT(-0500)] <yura> well yes
[12:59:35 CDT(-0500)] <yura> it will do it
[12:59:37 CDT(-0500)] <yura> I m really interested in hearing your feedback for demands work
[12:59:47 CDT(-0500)] <Bosmon2> Yes, it looks good, in structure
[12:59:56 CDT(-0500)] <Bosmon2> I guess the names still make me a bit uneasy
[13:00:09 CDT(-0500)] <Bosmon2> Although it is named "demandingName" in our documentation I'm not convinced anyone understands anything by this
[13:00:10 CDT(-0500)] <yura> any concerns about having the base.json ?
[13:00:24 CDT(-0500)] <yura> yes this is exactly where i got it from
[13:00:29 CDT(-0500)] <Bosmon2> yes
[13:00:39 CDT(-0500)] <yura> funcName is confusin too, since it shows up in demands spec itself
[13:00:42 CDT(-0500)] <Bosmon2> We should probably have another big naming discussion when colinclark appears
[13:00:57 CDT(-0500)] <Bosmon2> Since these names will appear in our configuration files FROM NOW UNTIL THE END OF TIME
[13:01:04 CDT(-0500)] <yura> ok so ill update everything and fix the algo and let you know ?
[13:01:06 CDT(-0500)] <Bosmon2> base.json seems fine
[13:01:19 CDT(-0500)] <yura> the name is ok ? i did not want to call it default.json
[13:01:26 CDT(-0500)] <Bosmon2> That seems ok to me
[13:01:35 CDT(-0500)] <yura> thanks! ill let you know as soon as i m done
[13:02:05 CDT(-0500)] <Bosmon2> The "demandSpec" container seems unnecessary?
[13:02:34 CDT(-0500)] <yura> why it might have more than just options
[13:02:37 CDT(-0500)] <yura> waay more
[13:02:48 CDT(-0500)] <Bosmon2> Well, it can only have things drawn from a fixed and finite set
[13:03:02 CDT(-0500)] <Bosmon2> And so it seems on the face of it unnecessary
[13:05:13 CDT(-0500)] <Bosmon2> I think the full set consists of funcName/options/arg
[13:05:16 CDT(-0500)] <Bosmon2> args
[13:05:19 CDT(-0500)] <Bosmon2> Can there be anything else?
[13:05:49 CDT(-0500)] <Bosmon2> Ignoring, of course, things that we hate and plan to destroy
[13:06:25 CDT(-0500)] <yura> oh by the way, what do you prefer: http://pastie.org/5099365 vs http://pastie.org/5099373
[13:06:56 CDT(-0500)] <Bosmon2> Hey there colinclark
[13:07:16 CDT(-0500)] <colinclark> hey there Bosmon2!
[13:07:34 CDT(-0500)] <Bosmon2> We are having a bit of a naming discussion
[13:07:40 CDT(-0500)] <Bosmon2> If you have some spare cycles to weigh in some time
[13:07:47 CDT(-0500)] <Bosmon2> I am thinking that I hate the term "demandingName"
[13:07:47 CDT(-0500)] <colinclark> ooh, my favourite
[13:07:52 CDT(-0500)] <Bosmon2> As potentially confusing and meaningless
[13:08:02 CDT(-0500)] <Bosmon2> yura is working on his declarative encoding of demands blocks system
[13:08:44 CDT(-0500)] <yura> if only it was the key of a json object , there would be no need for a name
[13:08:53 CDT(-0500)] <Bosmon2> yura - I prefer the latter, but fear it won't work until the framework is fixed?
[13:09:10 CDT(-0500)] <Bosmon2> We still have to be incredibly careful about using our allowance of demands blocks
[13:09:47 CDT(-0500)] <Bosmon2> yura - that's correct, but I suspect there's no alternative to this approach
[13:09:55 CDT(-0500)] <yura> Bosmon2: it certainly looks less nested AND only components that demand things see/get them
[13:10:09 CDT(-0500)] <Bosmon2> In the future, it may be possible to have ONE AND THE SAME combination of function name and context names in two different demands blocks
[13:10:16 CDT(-0500)] <Bosmon2> But expect the system to honour both of them
[13:10:28 CDT(-0500)] <Bosmon2> Right now of course we have the limitation that only one demands block is ever honoured
[13:10:35 CDT(-0500)] <Bosmon2> But we can't design our encoding system around this assumption
[13:11:06 CDT(-0500)] <yura> well ok why cant i simply write "someComponents": [ , ...]
[13:13:01 CDT(-0500)] <Bosmon2> yura - hopefully this will be allowed as a choice
[13:13:13 CDT(-0500)] <Bosmon2> But I worry that right now we should write our configuration files conservatively
[13:13:20 CDT(-0500)] <Bosmon2> Even if it means they end up in an unfortunate "pointy" style...
[13:13:47 CDT(-0500)] <yura> Bosmon2: you mean one config vs the other ?
[13:14:10 CDT(-0500)] <Bosmon2> yura - presumably both of them are legal right now?
[13:14:15 CDT(-0500)] <yura> yes
[13:14:54 CDT(-0500)] <Bosmon2> So I think we would follow whatever style here that we would use had this configuration been written out in code....
[13:15:12 CDT(-0500)] <yura> ok
[13:15:29 CDT(-0500)] <Bosmon2> And hope that the framework gets fixed soon
[15:15:05 CDT(-0500)] <yura> Bosmon2: hi
[15:23:14 CDT(-0500)] <Bosmon2> Hmm
[15:23:20 CDT(-0500)] <Bosmon2> Somehow I'm not getting the flashing animation now
[15:23:27 CDT(-0500)] <Bosmon2> Perhaps it is because I am Bosmon2.....
[15:25:07 CDT(-0500)] <yura> so Bosmon
[15:25:28 CDT(-0500)] <yura> I am thinking of some sort of process of combining config files from different gpii/node_modules
[15:25:30 CDT(-0500)] <yura> for example
[15:25:42 CDT(-0500)] <yura> if I want to deploy pref server and solutions registry on one node
[15:26:07 CDT(-0500)] <yura> right now i have a config that looks like an aggregate of pref server and solution registry configs
[15:26:31 CDT(-0500)] <yura> instead i should probably reference them in that config rather than just copying
[15:27:07 CDT(-0500)] <Bosmon> yura - if the configuration is "the same" it should actually be the same
[15:27:31 CDT(-0500)] <Bosmon> The best mechanism for reuse of configuration would be the use of GRADES
[15:28:18 CDT(-0500)] <yura> can you give an example please ?
[15:30:48 CDT(-0500)] <Bosmon> Well, if something is "the same" it should be expressed through that same thing appearing as a grade parent
[15:31:04 CDT(-0500)] <Bosmon> Only those things which are different should appear in the end configuration