Skip to end of metadata
Go to start of metadata

[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>

[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 // - 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> ""

[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 (smile)

[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 (smile)

[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 (smile)

[13:06:25 CDT(-0500)] <yura> oh by the way, what do you prefer: vs

[13:06:56 CDT(-0500)] <Bosmon2> Hey there colinclark (smile)

[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 (smile)

[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 (smile)

[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": [

Unknown macro: {context}

, ...]

[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 (smile)

[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

  • No labels