fluid-tech IRC Logs-2012-11-05

[12:45:21 CST(-0600)] <Bosmon2> yura and I are talking about his "base config"

[12:45:27 CST(-0600)] <Bosmon2> Which he continues to insist on doing in private chat : P

[12:45:54 CST(-0600)] <yura> wow , i never insisted

[12:46:06 CST(-0600)] <Bosmon2> Well, I already asked you to move to the channel once

[12:46:32 CST(-0600)] <yura> Bosmon2: so yes

[12:46:39 CST(-0600)] <yura> loading multiple base configs

[12:46:42 CST(-0600)] <Bosmon2> yura has moved our defaults and demands blocks into a fully declarative form

[12:46:44 CST(-0600)] <yura> for every little thing

[12:47:13 CST(-0600)] <Bosmon2> But it seems clear that, although we plan to not implement a "conditional includes system" as far as possible, we will still need an "includes system"

[12:47:30 CST(-0600)] <Bosmon2> Similar to the "modules system" which we have also not invented

[12:47:47 CST(-0600)] <Bosmon2> But given that there isn't any node equivalent for this at all, we will have to at least do SOMETHING

[12:47:48 CST(-0600)] <yura> ok

[12:48:04 CST(-0600)] <yura> so we already have a require configs for our test environment

[12:48:06 CST(-0600)] <Bosmon2> Some kind of JSON file listing the location of declarative dependencies in other JSON files

[12:48:07 CST(-0600)] <yura> something similar

[12:48:08 CST(-0600)] <yura> ?

[12:48:41 CST(-0600)] <Bosmon2> yura - something similar, yes

[12:50:01 CST(-0600)] <yura> well there's a tricky part

[12:50:38 CST(-0600)] <yura> Bosmon2: lets say i have a config that includes other ones, what if they are needed not in their entirety

[12:50:39 CST(-0600)] <yura> ?

[12:50:45 CST(-0600)] <yura> but only demands lets say

[12:56:09 CST(-0600)] <yura> Bosmon2: ^

[13:49:37 CST(-0600)] <Bosmon> Sorry, somehow I am not getting notifications on the other nick

[13:50:03 CST(-0600)] <Bosmon> yura - the idea of "not being needed in their entirety" is as we noted last week "anti-religious" : P

[13:51:10 CST(-0600)] <yura> btu you are talking about demands

[13:51:18 CST(-0600)] <yura> we have more than just demands in those files

[13:51:24 CST(-0600)] <Bosmon> yura - in which files

[13:53:50 CST(-0600)] <yura> in all files pretty much

[13:54:14 CST(-0600)] <Bosmon> Can you be more specific

[13:54:25 CST(-0600)] <Bosmon> Bosmon2: lets say i have a config that includes other ones, what if they are needed not in their entirety

[13:54:32 CST(-0600)] <Bosmon> I believe we are still dealing with this issue

[13:54:44 CST(-0600)] <Bosmon> What might be the risk of including "too much configuration"?

[13:54:55 CST(-0600)] <yura> sure

[13:56:20 CST(-0600)] <yura> for example https://github.com/yzen/universal/blob/GPII-43/gpii/node_modules/preferencesServer/configs/base.json

[13:57:08 CST(-0600)] <Bosmon> This one looks ok

[13:57:52 CST(-0600)] <yura> i guess it does

[13:58:35 CST(-0600)] <yura> Bosmon: ok i cant find an example i was thinking before

[13:58:57 CST(-0600)] <yura> but then what would you suggest should be the mechanism for finding and including those configs?

[13:59:04 CST(-0600)] <Bosmon> We just need a way to modularise our demands blocks into separate files that is at least as good as the one we had before when they were in in .js files : P

[13:59:09 CST(-0600)] <yura> a new "includes" structure in config ?

[13:59:10 CST(-0600)] <Bosmon> We don't need anything magically better than that

[13:59:18 CST(-0600)] <Bosmon> yura - yes, something like that

[13:59:33 CST(-0600)] <yura> ok ill take a look

[14:01:49 CST(-0600)] <yura> oh ok here's the question

[14:02:00 CST(-0600)] <yura> so my base.json that includes all demands

[14:02:10 CST(-0600)] <yura> would otherwise load them from includes block

[14:02:20 CST(-0600)] <yura> but it will also include options block

[14:02:42 CST(-0600)] <yura> which might have too many options if all of them will be merged

[14:03:27 CST(-0600)] <Bosmon> I thought the idea behind "base" was to only include those things which were valid in all configurations

[14:05:29 CST(-0600)] <yura> alright

[14:05:38 CST(-0600)] <yura> makes sense

[14:07:14 CST(-0600)] <Bosmon> Whilst our demands block system is still broken, we'll always need to do a bit of "include juggling" - but we should try to make it as little as possible

[15:00:15 CST(-0600)] <yura> so Bosmon does it mean that with include section i do not need base.json anymore ?

[15:00:40 CST(-0600)] <Bosmon> yura - it may, depending on how you have laid it out : P

[15:00:40 CST(-0600)] <yura> and by that i mean i can just include it instead of manually looking it up

[15:00:56 CST(-0600)] <Bosmon> You mean the convention of looking for a file named base.json?

[15:01:05 CST(-0600)] <yura> ya

[16:14:41 CST(-0600)] <yura> Bosmon: please let me know what you think of this https://github.com/yzen/universal/commit/8ade10defc4dc337ab6fc6a2cf358d7907217494

[16:16:17 CST(-0600)] <Bosmon> yura - looks reasonable

[16:16:22 CST(-0600)] <Bosmon> What's the state of the "giant base.json"?

[16:17:05 CST(-0600)] <yura> well i did not want to touch it until you see this part

[16:17:13 CST(-0600)] <yura> but it will be similar

[16:17:23 CST(-0600)] <Bosmon> This so far looks broadly rational

[16:17:38 CST(-0600)] <Bosmon> THe duplication in the demands JSON files is regrettable but I guess necessary

[16:17:51 CST(-0600)] <Bosmon> Well

[16:17:54 CST(-0600)] <Bosmon> Actually they are not demands

[16:18:17 CST(-0600)] <Bosmon> But I guess you can't get merging done - UNLESS you go with the grade-based idea I mentioned before

[16:18:39 CST(-0600)] <Bosmon> YOu could simply define the material that used to be in base.json as a grade named gpii.basePreferencesServer

[16:18:46 CST(-0600)] <Bosmon> or some similar name

[16:18:53 CST(-0600)] <yura> yes

[16:18:54 CST(-0600)] <yura> ok ill try to finish it and will let you know

[16:18:55 CST(-0600)] <Bosmon> And then you could refer to that as a base grade in the separate json files

[16:19:12 CST(-0600)] <yura> thanks ill take a look