fluid-work IRC Logs-2013-04-08

[08:32:01 CDT(-0500)] <colinclark> jessm: Hey

[08:32:10 CDT(-0500)] <colinclark> I'm on the "Common Terms Registry" meeting at the moment

[08:32:23 CDT(-0500)] <jessm> colinclark: cool

[08:32:25 CDT(-0500)] <colinclark> and there's a lot of talk about actually building it

[08:33:12 CDT(-0500)] <colinclark> This is another one of these things that is somewhat on the periphery of our Floe/PGA work, but there's pressure to make happen

[08:33:27 CDT(-0500)] <colinclark> and I really don't want developers to be writing code for this thing without at least a basic design

[08:34:21 CDT(-0500)] <jessm> colinclark: ah ha

[08:34:33 CDT(-0500)] <jessm> seems like i should make a list...

[08:34:42 CDT(-0500)] <jessm> we have a growing list of design activities

[08:34:49 CDT(-0500)] <colinclark> Yeah, that's what I was thinking

[08:35:02 CDT(-0500)] <colinclark> I'm happy to help chat about priorities for all these things

[08:35:10 CDT(-0500)] <colinclark> as well as doing my best to explain what they actually are

[08:35:39 CDT(-0500)] <jessm> colinclark: yes and YES to that

[08:35:48 CDT(-0500)] <jessm> esp. since there have been some big changes lately

[08:35:52 CDT(-0500)] <jessm> to the CTR

[08:36:05 CDT(-0500)] <danaayotte> colinclark jessm I'm happy to do some designing

[08:36:50 CDT(-0500)] <colinclark> wicked

[08:37:01 CDT(-0500)] <colinclark> jessm: Fortunately, the big changes to the CTR are good ones

[08:37:06 CDT(-0500)] <colinclark> massive simplification

[08:37:21 CDT(-0500)] <jessm> roger that

[08:37:39 CDT(-0500)] <jessm> colinclark: should we have another designerly chat and actually let you talk this time?

[08:37:45 CDT(-0500)] <colinclark> lol

[08:37:51 CDT(-0500)] <colinclark> Be careful what you wish for

[08:37:57 CDT(-0500)] <colinclark> but I'd be happy to

[08:38:06 CDT(-0500)] <jessm> well, talk, within reason

[08:38:27 CDT(-0500)] <jessm> tomorrow we have PMT/PCP in the a.m.

[08:38:31 CDT(-0500)] <jessm> should we chit chat after?

[08:38:36 CDT(-0500)] <jessm> 10 ish?

[08:38:54 CDT(-0500)] <colinclark> ok, sounds good

[08:38:57 CDT(-0500)] <colinclark> it's in my calendar

[08:39:18 CDT(-0500)] <jessm> danaayotte: that work for you?

[08:39:35 CDT(-0500)] <danaayotte> yes

[08:46:13 CDT(-0500)] <jessm> danaayotte: can you double-check that i got all the "blanks" pages from the wiki with CMHR stuff on 'em?

[08:46:51 CDT(-0500)] <danaayotte> jessm: looks good, thanks

[09:11:05 CDT(-0500)] <heidiv> fyi Justin_o i've started a jira for investigating carousel widget options here: http://issues.fluidproject.org/browse/FLUID-4972

[09:11:14 CDT(-0500)] <Justin_o> heidiv: thanks

[09:11:59 CDT(-0500)] <colinclark> heidiv: Am I right in thinking that you'll need jvass to answer a few of the interaction questions on this JIRA?

[09:12:09 CDT(-0500)] <colinclark> Such as specifying the scrolling behaviour, etc.?

[09:12:19 CDT(-0500)] <heidiv> colinclark she's started a wiki page that i reference in the jira

[09:12:36 CDT(-0500)] <colinclark> ah, great

[10:02:07 CDT(-0500)] <michelled> anastasiac, arashs, cindyli, heidiv, Justin_o: can we have a quick meeting to estimate some of the work that we talked about on Friday?

[10:02:22 CDT(-0500)] <cindyli> sure, michelled

[10:02:23 CDT(-0500)] <arashs> sure

[10:02:28 CDT(-0500)] <anastasiac> in the collar room, michelled?

[10:02:46 CDT(-0500)] <heidiv> sure, skype me?

[10:03:11 CDT(-0500)] <michelled> collab room is busy - let's meet near the kitchen. yes, heidiv, Justin_o will Skype you and cindyli in

[10:03:30 CDT(-0500)] <heidiv>

[10:37:31 CDT(-0500)] <supungs> Hi

[10:42:42 CDT(-0500)] <system64> Morning colinclark!

[10:43:19 CDT(-0500)] <colinclark> Hey system64, how's it going?

[10:45:11 CDT(-0500)] <system64> colinclark: Doing great! Checked out Flocking this weekend

[10:45:41 CDT(-0500)] <system64> colinclark: Its simply awesome!

[10:46:41 CDT(-0500)] <colinclark> Oh wow

[10:46:44 CDT(-0500)] <colinclark> thanks for saying that

[10:46:54 CDT(-0500)] <colinclark> There's still a lot of work to do, but it's coming along nicely

[10:48:07 CDT(-0500)] <colinclark> system64: Have you been thinking any more about the two projects you were interested in?

[10:50:40 CDT(-0500)] <system64> Yeah! I think the Music Development Environment is going to be a huge thing. But I don't have experience with DSP and digital audio.

[10:52:09 CDT(-0500)] <colinclark> I think a willingness to learn is the key

[10:52:29 CDT(-0500)] <colinclark> If you feel like you can learn as you go, you can probably describe how you'll do that in your project proposal

[10:52:48 CDT(-0500)] <colinclark> and the more specific you are--e.g. sources you'll refer to etc., the better it will probably be

[10:55:46 CDT(-0500)] <system64> colinclark: I'm still not clear about the project though, are we going to build something like 'JAM with Chrome'?

[11:12:00 CDT(-0500)] <system64> colinclark: I've been looking into Web Audio for sometime now, it was actually the Web Audio API that got my interest into Digital Audio. I'd like to admit I still don't understand most things. But I'm certainly up for the learning curve!

[11:28:01 CDT(-0500)] <colinclark> sounds great, system64

[11:28:08 CDT(-0500)] <colinclark> I think the idea of the project is still somewhat open-ended

[11:28:40 CDT(-0500)] <colinclark> but the idea is to create an environment where musicians can create instruments with Flocking's declarative JSON format, and then wire those synths up to different types of controls

[11:31:12 CDT(-0500)] <system64> colinclark: Are we going to create instruments with flocking?

[11:32:00 CDT(-0500)] <colinclark> Yes, I think that would probably make sense

[11:35:16 CDT(-0500)] <system64> I'm not able to try it now, but I think 'JAM with Chrome' was something similar. Have you tried it?

[11:49:34 CDT(-0500)] <colinclark> I haven't, no

[12:15:21 CDT(-0500)] <anastasiac> michelled, the video player WordPress plugin is ready for another review: https://github.com/inclusive-design/infusion-videoPlayer-wp-plugin/pull/5

[12:15:30 CDT(-0500)] <michelled> thanks anastasiac

[12:25:59 CDT(-0500)] <colinclark> anastasiac: Great post to the a11y-metadata list!

[12:26:20 CDT(-0500)] <anastasiac> thanks, colinclark

[12:27:27 CDT(-0500)] <michelled> colinclark: Justin_o and I were just talking about our criteria for getting his branch in master

[12:27:58 CDT(-0500)] <michelled> I'm proposing that we get the branch to a state where we are happy to see it in master, but we still expect to do some more work on it.

[12:28:26 CDT(-0500)] <colinclark> Seems reasonable, as long as there are clear to dos and JIRAs filed for them

[12:28:26 CDT(-0500)] <michelled> for example, the IE tests are currently failing in master

[12:28:54 CDT(-0500)] <michelled> I'm suggesting that instead of spending the estimated 4 days to fix them now, we get the new branch in first and then fix them

[12:29:38 CDT(-0500)] <colinclark> Yeah, I think that's fine

[12:29:44 CDT(-0500)] <Justin_o> colinclark, michelled: those aren't specific to our repo, the master has failing IE tests

[12:29:46 CDT(-0500)] <colinclark> again, clear JIRAs are the key

[12:30:09 CDT(-0500)] <michelled> cool

[12:31:08 CDT(-0500)] <michelled> as I was saying to Justin_o, it would be really nice to get my master back

[12:31:17 CDT(-0500)] <colinclark> no kidding!

[12:31:18 CDT(-0500)] <michelled> I read my sticky note every day and freak out a little

[12:31:56 CDT(-0500)] <colinclark>

[12:38:19 CDT(-0500)] <Justin_o> bosmon, colinclark, michelled: would one of you like to review my new pull request https://github.com/fluid-project/infusion/pull/310

[14:06:27 CDT(-0500)] <colinclark> Bosmon: Your friend Alex wrote a blog post about the Blink fork. I though his comments near the end about it being related to "dependencies and reducing abstractions" was quite interesting: http://infrequently.org/2013/04/probably-wrong/

[14:06:37 CDT(-0500)] <colinclark> It is written with his typical rhetorical style as well

[14:13:23 CDT(-0500)] <Bosmon> "My friend" Alex has exactly the argumentative stance as Microsoft apologists like Raymond Chen

[14:15:24 CDT(-0500)] <Bosmon> It's no surprise that his "citation" for his final comment is himself

[14:16:12 CDT(-0500)] <Bosmon> Which contains a half-baked farrago of poorly understood History of Science : P

[14:16:48 CDT(-0500)] <Bosmon> In fact his statement is equivalent to the well-known fallacy known as "Politician's Logic": "Something must be done! This is something - therefore we must do it"

[14:22:36 CDT(-0500)] <Bosmon> Hi Justin_o - I had a look at your issue, but I can't reproduce it

[14:22:46 CDT(-0500)] <Bosmon> Can you tell me exactly what happens, and on what platform?

[14:23:57 CDT(-0500)] <Justin_o> Bosmon: you're talking about the one for my pull request right

[14:24:02 CDT(-0500)] <Bosmon> Justin_o - yes

[14:24:15 CDT(-0500)] <Justin_o> Bosmon: i ran into that with the FLUID-4927 branch

[14:24:19 CDT(-0500)] <Bosmon> What did you observe that made you file FLUID-4973?

[14:25:52 CDT(-0500)] <Justin_o> we would get radom failures in IE8 and which would try to call your console logs… when it would hit the applyHostFunction and try to trigger the Function.prototype.bind you would then get a browser error

[14:26:11 CDT(-0500)] <Justin_o> note that the test wasn't initially failing because of this, just an additional issue to go along with it

[14:26:39 CDT(-0500)] <Bosmon> Justin_o - that should be impossible because typeof (console.log) === "function" always returns false on IE8

[14:26:50 CDT(-0500)] <Bosmon> Do you have something in your branch that can demonstrate the problem?

[14:28:07 CDT(-0500)] <Justin_o> Bosmon: um.. i'll have to take a look.. i was trying something out at the time that i reverted

[14:28:49 CDT(-0500)] <Bosmon> Justin_o - Either way, we need a test case to demonstrate that this fix is needed

[14:30:34 CDT(-0500)] <Justin_o> Bosmon: okay.. although i like your suggestion better of just getting rid of applyHostFunction

[14:31:06 CDT(-0500)] <Bosmon> We only put it there in the first place because of a very similar situation

[14:31:13 CDT(-0500)] <Bosmon> We got a report of a failure from Harris that none of us could reproduce

[14:31:24 CDT(-0500)] <Justin_o> Bosmon: oh

[14:31:34 CDT(-0500)] <Justin_o> Bosmon: would you like me to make you a test case then..

[14:31:39 CDT(-0500)] <Justin_o> for my issue

[14:32:05 CDT(-0500)] <Bosmon> Justin_o - yes, we need to have at least some idea how to demonstrate the failure

[14:32:18 CDT(-0500)] <Bosmon> Right now I don't have any problems running our fluid.log in IE8 either with or without the console

[14:32:25 CDT(-0500)] <Bosmon> I think we would have noticed a failure so blatant

[14:33:13 CDT(-0500)] <Justin_o> Bosmon: yes, you'd think

[14:33:30 CDT(-0500)] <Justin_o> could be some other interaction.. i'll try to write up a test case to go along with my pull request

[14:33:38 CDT(-0500)] <Bosmon> Thanks, Justin_o

[14:33:56 CDT(-0500)] <Justin_o> Bosmon: also, did you have a chance to read the chat logs about the FLUID-4927 pull request

[14:34:13 CDT(-0500)] <Bosmon> Justin_o - which day should I look at?

[14:35:22 CDT(-0500)] <Justin_o> Bosmon: today

[14:35:25 CDT(-0500)] <Justin_o> just shortly after you left

[14:39:17 CDT(-0500)] <Bosmon> Justin_o - it seems that michelled was suggesting less stringent criteria for approving our branch?

[14:39:46 CDT(-0500)] <Bosmon> Rather than "it needs to be good enough to ship", we are thinking of something more like "It runs without obvious problems on all platforms"?

[14:40:12 CDT(-0500)] <Bosmon> colinclark - I think this one is a far more honest summary of the meaning of "Blink" : P http://prng.net/blink-faq.html

[14:40:29 CDT(-0500)] <colinclark> Yes, I read that one after Alex's

[14:42:28 CDT(-0500)] <Bosmon> colinclark - and this one is more than slightly reminiscent of an argument of Ray's during the Sakai years: "If there is wisdom in the Chrome team, it is that these projects are not only recognized as important, but the very best engineers volunteer to take them on."

[14:43:11 CDT(-0500)] <Bosmon> "Smart developers are easily bored, so we need to produce shiny but possibly spurious modernity on a regular basis to keep them entertained"

[14:43:48 CDT(-0500)] <colinclark> I just read something about Oracle, of all companies, preparing a WebKit-based browser with their own JavaScript engine

[14:43:49 CDT(-0500)] <colinclark> http://en.wikipedia.org/wiki/Nashorn_%28JavaScript_engine%29

[14:44:10 CDT(-0500)] <colinclark> bizarre

[14:44:14 CDT(-0500)] <Bosmon> Interesting that that is still rumbling on

[14:45:02 CDT(-0500)] <Bosmon> Although the fact they released it to OpenJDK suggests, unfortunately, that Oracle may no longer consider it strategic

[14:45:18 CDT(-0500)] <Bosmon> They are not the kind of company who perceives intrinsic value in open sourcing their products

[14:45:35 CDT(-0500)] <colinclark> indeed

[14:45:58 CDT(-0500)] <colinclark> This is one of the reasons why I'm increasingly concerned about the preponderance of Java-based code in Cloud4all

[14:46:22 CDT(-0500)] <colinclark> I have no confidence at all that Java will be much more than a language one uses for building Android apps in, say, five years

[14:46:31 CDT(-0500)] <colinclark> But perhaps I'm being optimisitc

[14:46:32 CDT(-0500)] <michelled> Bosmon: my other criteria is that we don't make anything worse than what's in master. meaning, the code should be at least the same quality as what's in there and tests that are passing should still be passing.

[14:47:07 CDT(-0500)] <Bosmon> michelled - that seems reasonable

[14:47:32 CDT(-0500)] <Bosmon> This implies that what we commit will have to have SOME kind of version of "options mapping code" even if it only extends to the old panel configurations

[14:47:37 CDT(-0500)] <Bosmon> colinclark - "Java won't curl up and die like Cobol, insists Oracle" : P

[14:47:44 CDT(-0500)] <Bosmon> http://www.theregister.co.uk/2012/03/07/oracle_java_9_10_roadmap/

[14:47:55 CDT(-0500)] <colinclark> What a great headline

[14:48:11 CDT(-0500)] <Bosmon> Amazingly "Java is becoming the new Cobol" dates from 2007 ......

[14:48:49 CDT(-0500)] <Bosmon> Just 6 months before we came to that conclusion ourselves : P

[14:49:04 CDT(-0500)] <colinclark> I imagine, outside of deeply-entrenched enterprises, that the vast majority of new Java projects are, in fact, Android applications

[14:49:30 CDT(-0500)] <colinclark> and I guess the legal case makes it clear that Oracle has absolutely none of the old Sun-style "Java certified" control over it

[14:50:04 CDT(-0500)] <Bosmon> My feeling is that "Java 8" and further will have something like the dusty status of such modern products as "Fortran 90" : P

[14:50:34 CDT(-0500)] <Bosmon> "We felt we had to modernise this thing but overlooked the fact that all of our remaining users are still here only because they need something that doesn't change"

[14:50:59 CDT(-0500)] <colinclark> lol

[15:16:19 CDT(-0500)] <Justin_o> Bosmon: i was looking into FLUID-4973 to try to write you a test case, but haven't been able to yet and have to run now. However, I've found a rather obscure way to reproduce it in the FLUID-4927 branch

[15:16:28 CDT(-0500)] <Bosmon> Justin_o - excellent

[15:16:38 CDT(-0500)] <Justin_o> Bosmon: to reproduce, you have to run the Settings Panels Tests

[15:16:44 CDT(-0500)] <Bosmon> Although hopefully this doesn't amount to replacing "console.log" with a function of your own devising

[15:17:04 CDT(-0500)] <Justin_o> Bosmon: open the IE8 debugger, make sure it is using the proper IE8 modes for everything and then start debugging

[15:17:16 CDT(-0500)] <Justin_o> periodically it will hit the error, but not every time

[15:17:27 CDT(-0500)] <Bosmon> Justin_o: !!!!

[15:17:29 CDT(-0500)] <Justin_o> haha, no i didn't do that

[15:17:52 CDT(-0500)] <Bosmon> PERIODICALLY IT WILL HIT THE ERROR BUT NOT EVERY TIME!!?

[15:18:48 CDT(-0500)] <Bosmon> Justin_o - should I use your FLUID-4927 branch, or FLUID-4927-b, or some other one?

[15:19:56 CDT(-0500)] <Justin_o> Bosmon: FLUID-4927-b

[15:20:08 CDT(-0500)] <Justin_o> i suppose you could also use cindy's from the pull request

[15:21:11 CDT(-0500)] <Bosmon> Justin_o - I tried it and it seemed to work fine

[15:21:27 CDT(-0500)] <Bosmon> What does "make sure it is using the proper IE8 modes for everything" involve?

[15:22:32 CDT(-0500)] <Justin_o> Bosmon: when you open the IE debugger, there is a set of menus at the top. (like any windows app)

[15:22:56 CDT(-0500)] <Justin_o> the two to the right Browser Mode: and Document Mode should be set to IE8 and IE8 Standards respectively

[15:23:00 CDT(-0500)] <Bosmon> Yes

[15:23:02 CDT(-0500)] <Bosmon> Those are set

[15:23:11 CDT(-0500)] <Bosmon> But I don't see any failure with the logging

[15:23:15 CDT(-0500)] <Justin_o> Bosmon: good.. did you click the "Start Debugging" button

[15:23:24 CDT(-0500)] <Bosmon> Ah no

[15:23:28 CDT(-0500)] <Bosmon> Ok, I've done that now

[15:23:34 CDT(-0500)] <Justin_o> now refresh the page..

[15:23:44 CDT(-0500)] <Bosmon> It still worked

[15:23:46 CDT(-0500)] <Justin_o> it only happens periodically so you might have to try a few times

[15:24:23 CDT(-0500)] <Bosmon> got it

[15:24:31 CDT(-0500)] <Bosmon> On my 8th refresh : P

[15:24:34 CDT(-0500)] <Bosmon> Sodding sod

[15:24:38 CDT(-0500)] <Justin_o> that's better than me

[15:24:50 CDT(-0500)] <Justin_o> i wonder if it's just a debugger bug now that we've stepped through it like this

[15:25:16 CDT(-0500)] <Bosmon> Justin_o - so, the reason is actually that it is trying to operate a fluid.fail

[15:25:27 CDT(-0500)] <Bosmon> We actually have a synchronization problem in the testing framework

[15:25:43 CDT(-0500)] <Bosmon> The message it is trying to display is "Sequence error: attempt to use test environment which has already been destroyed"

[15:25:49 CDT(-0500)] <Justin_o> Bosmon: oh.. i think these test use the new framework too

[15:26:11 CDT(-0500)] <Bosmon> And the source of the error is actually the raw call to fluid.applyHostFunction on line 105 of fluid.logActivity

[15:26:18 CDT(-0500)] <Bosmon> Rather than a direct call to fluid.log

[15:27:00 CDT(-0500)] <Justin_o> Bosmon: ah.. so it is a bug, just not really the one i thought it was

[15:27:11 CDT(-0500)] <Bosmon> Justin_o - it is in fact two bugs

[15:27:28 CDT(-0500)] <Bosmon> Firstly the bug in the testing framework which causes the failure, and secondly the bug in fluid.logActivity which prevents it being logged

[15:28:50 CDT(-0500)] <colinclark> Bosmon: Is there anything in particular you did to deduce this?

[15:28:55 CDT(-0500)] <Justin_o> Bosmon: bugs are always traveling in groups eh… glad you were able to see it in action, i doubt i would have been able to track it down to the root cause

[15:29:08 CDT(-0500)] <Bosmon> colinclark - I just looked at the stack trace when I could reproduce the failure in IE8

[15:29:14 CDT(-0500)] <Justin_o> Bosmon: i have to run, but thanks for following up with this

[15:29:24 CDT(-0500)] <colinclark> Can you paste a copy of the stack trace you see, Bosmon?

[15:29:30 CDT(-0500)] <Bosmon> colinclark - I can't

[15:29:36 CDT(-0500)] <colinclark> I'm curious to take a look and don't have my IE VM running

[15:29:37 CDT(-0500)] <colinclark> ok

[15:29:42 CDT(-0500)] <Bosmon> Since every element of it says "JScript anonymous function"

[15:29:46 CDT(-0500)] <Bosmon> Actually every element except one

[15:29:49 CDT(-0500)] <Bosmon> Which says "fireToListeners"

[15:30:00 CDT(-0500)] <Bosmon> There's no alternative but going through each one by hand to see what it is................

[15:30:03 CDT(-0500)] <colinclark> But it gives you line numbers?

[15:30:07 CDT(-0500)] <colinclark> or you can click to see?

[15:30:11 CDT(-0500)] <Bosmon> colinclark - click to see

[15:30:17 CDT(-0500)] <Bosmon> No info in the GUI whatever

[15:30:26 CDT(-0500)] <colinclark> IE8 is still terrible

[15:30:27 CDT(-0500)] <colinclark> oh well

[15:30:37 CDT(-0500)] <Bosmon> IE8, like FORTRAN 77, will forever be what it is

[15:30:47 CDT(-0500)] <Bosmon> All we can hope is some day to be able to disuse it.......

[15:31:54 CDT(-0500)] <Bosmon> Probably the simplest test case for the fix would be to add a "fluid.logActivity" call somewhere in our testing suite

[15:32:17 CDT(-0500)] <Bosmon> This is actually incredibly recent code and was only introduced about the time of San Diego

[15:32:50 CDT(-0500)] <Bosmon> These are the functions that will assist sgithens in producing visualization tools

[15:33:47 CDT(-0500)] <colinclark> ah, yes

[15:33:48 CDT(-0500)] <colinclark> great

[16:04:00 CDT(-0500)] <colinclark> kasper: you still conscious?

[16:04:09 CDT(-0500)] <kasper> colinclark: more or less

[16:04:31 CDT(-0500)] <colinclark> Quick question?

[16:04:33 CDT(-0500)] <kasper> I'm debating whether to cook dinner, or just give up on eating

[16:04:33 CDT(-0500)] <kasper> sure

[16:04:38 CDT(-0500)] <Bosmon> colinclark - I just passed on the note about the duplicate MouseTrails

[16:04:50 CDT(-0500)] <colinclark> SECRETLY!

[16:05:22 CDT(-0500)] <kasper> colinclark, Bosmon: should be fixed now

[16:05:31 CDT(-0500)] <colinclark> I was wondering whether the Flatness Zombies will eat our brains for this hierarchy: https://github.com/kaspermarkus/universal/blob/pilots/testData/preferences/os_gnome.json

[16:05:42 CDT(-0500)] <Bosmon> "hierarchy? I see no hierarchy!"

[16:06:08 CDT(-0500)] <kasper> I agree with Le Bass

[16:06:12 CDT(-0500)] <colinclark> I guess we have three distinctions, but I find myself constantly confused

[16:06:17 CDT(-0500)] <colinclark> 1. Common terms

[16:06:25 CDT(-0500)] <colinclark> 2. Application-unique terms

[16:06:26 CDT(-0500)] <colinclark> and

[16:06:29 CDT(-0500)] <colinclark> 3. Just some settings

[16:06:39 CDT(-0500)] <colinclark> #1 and #2 are always pretty well flat

[16:06:54 CDT(-0500)] <colinclark> or at least, as flats as their definition allows them to be

[16:07:04 CDT(-0500)] <colinclark> whereas #3 is, well, "just some settings"

[16:07:13 CDT(-0500)] <colinclark> which I guess is what is in these sets of preferecnes

[16:07:35 CDT(-0500)] <kasper> so you want something crazy like: "http://registry.gpii.org/applications/org\\.gnome\\.desktop\\.a11y\\.magnifier.screen-position"?

[16:08:09 CDT(-0500)] <kasper> colinclark: Does our framework even support that?

[16:08:23 CDT(-0500)] <colinclark> Well, honestly, this looks like a quite sensible representation for application-specific settings as far as I'm concerned

[16:08:50 CDT(-0500)] <colinclark> though others, I suspect, will quite vehemently disagree

[16:09:39 CDT(-0500)] <colinclark> As for whether we support it, I guess I don't know

[16:09:47 CDT(-0500)] <colinclark> I'd have to get my head around what it actually means

[16:09:49 CDT(-0500)] <kasper> I guess there is a valid argument about not being able to describe contexts/sources/whatever of the individual settings in the way my NP sets are written

[16:09:50 CDT(-0500)] <colinclark> or even how it does it now

[16:10:15 CDT(-0500)] <kasper> well, the thing is right now, basically from the moment we read the preferences, they're ontologized

[16:10:48 CDT(-0500)] <kasper> (even the application specific terms - to the extend that one can ontologize these, meaning just an app-id block with settings in them)

[16:10:59 CDT(-0500)] <colinclark> right

[16:11:29 CDT(-0500)] <colinclark> presumably the "ontologization" would actually choose to gather up groups of app-specific preferences together into a single coherent block if it chose to?

[16:11:50 CDT(-0500)] <kasper> colinclark: I suggest we call a truce with the zombies until post-pilots (or post pilot-rush anyway) and then start having some serious meetings about the matchmaker framework, ontologies, transformations, contexts, NP formatting, etc

[16:12:12 CDT(-0500)] <kasper> yeah - that would make sense to me

[16:12:18 CDT(-0500)] <colinclark> I guess I was just hoping to understand how things actually work, why they work that way, and how we imagine they should work

[16:12:36 CDT(-0500)] <colinclark> but it is late

[16:12:47 CDT(-0500)] <kasper> "hoping to understand how things actually work" – I've given up on that a looooong time ago

[16:13:06 CDT(-0500)] <Bosmon> DAMN YOU, KASPARNET

[16:13:14 CDT(-0500)] <colinclark> actually, this is interesting, kasper

[16:13:20 CDT(-0500)] <colinclark> Let me find a link to an email I just discovered

[16:13:33 CDT(-0500)] <colinclark> where some frustration was raised about preferences that look just like this

[16:13:48 CDT(-0500)] <colinclark> you will be, I guess, unimpressed with my response

[16:14:01 CDT(-0500)] <colinclark> Are there archives for the SP3 mailing list?

[16:14:14 CDT(-0500)] <colinclark> I assume that would be far to useful a feature to have provided

[16:14:35 CDT(-0500)] <colinclark> Short form of the email:

[16:14:42 CDT(-0500)] <kasper> colinclark: afc there arent archives for those

[16:14:47 CDT(-0500)] <kasper> ofc*

[16:15:17 CDT(-0500)] <colinclark> Christophe: "So we can't write something like: http://wiki.gpii.net/index.php/SmartHouses_Preference_Sets#Flat_Preference_Set_for_Nitesh , we'll need to rewrite it?"

[16:15:24 CDT(-0500)] <colinclark> Me: "No, that's not the case. You do not need to rewrite your preferences sets. The preferences set for Nitesh should work just fine."

[16:16:04 CDT(-0500)] <kasper> hahaha

[16:16:17 CDT(-0500)] <colinclark> February 20 (or 21st in your timezone), 2013 from me to Christophe, in case you want to find it yourself

[16:16:26 CDT(-0500)] <kasper> well - I guess he might be able to tell us whether it actually works then

[16:16:56 CDT(-0500)] <colinclark> Here's the mistaken assumption I made

[16:17:09 CDT(-0500)] <colinclark> Me: "Again, there is no need to change anything on your part. Presumably, at this point, you've had lots of time to test your Matchmaker implementation and test profiles with the 0.1 system and it's working nicely, which is great."

[16:17:32 CDT(-0500)] <colinclark> Which, given the fact that you're desperately trying to make the RBMM work only now, was clearly not the case at the time

[16:17:59 CDT(-0500)] <colinclark> But this is what worries me a bit about seeing these preferences sets… are they consistent with what the Statistical MM is expecting?

[16:18:02 CDT(-0500)] <colinclark> I suspect not?

[16:18:42 CDT(-0500)] <colinclark> I'm trying to think through how ontologization fits into all of this

[16:19:01 CDT(-0500)] <kasper> I think that I at some point told Andy that he should use the format that I have in my example NPs, but not sure

[16:19:13 CDT(-0500)] <colinclark> Presumably you need to do an initial transformation of app-specific to common prior to ontologization...

[16:19:33 CDT(-0500)] <kasper> well, we have a general problem with ontologization

[16:19:37 CDT(-0500)] <colinclark> And as part of that conversion, presumably we should also be "repackaging" the application-specific preferences that remain after the transformation

[16:19:47 CDT(-0500)] <kasper> in that it doesn't allow us to pass around important info like context and source

[16:20:03 CDT(-0500)] <colinclark> We don't support context or source currently, do we?

[16:20:20 CDT(-0500)] <kasper> no - but it's impossible to do with the current ontologized format

[16:20:54 CDT(-0500)] <colinclark> Right but, well, so what?

[16:20:54 CDT(-0500)] <colinclark>

[16:21:18 CDT(-0500)] <kasper> haha, ok point taken

[16:21:27 CDT(-0500)] <colinclark> I guess the key point with "ontologization" is that it represents what I think is a critical step in the process of "understanding a preferences set"

[16:21:33 CDT(-0500)] <colinclark> I don't know why I'm randomly using quotations marks

[16:21:41 CDT(-0500)] <colinclark> So, I'll try to back up

[16:21:43 CDT(-0500)] <colinclark> feel free to nod off

[16:21:45 CDT(-0500)] <colinclark> or go cook

[16:22:08 CDT(-0500)] <kasper> I've already turned on the oven so I can through a pizza in there (like any other proud computer nerd)

[16:22:23 CDT(-0500)] <colinclark> In an ideal world, perhaps, preferences could actually be represented in the preferences set in a variety of "ontological formats"

[16:22:43 CDT(-0500)] <colinclark> Perhaps that's a dangerous assumption, but I think it's one we debated a lot during those phone calls with yzen and Bosmon

[16:22:57 CDT(-0500)] <colinclark> Which I am now acutely regretting having not summarized properly

[16:23:21 CDT(-0500)] <colinclark> Meaning, we can imagine that the user's sets can mix up preferences from different ontologies

[16:23:24 CDT(-0500)] <colinclark> but anyway, regardless of that

[16:23:30 CDT(-0500)] <colinclark> simplifying for a second

[16:24:11 CDT(-0500)] <colinclark> in the way that the Flatists love, but I think is rather problematic, we can imagine that all settings are really just term name/value pairs

[16:24:15 CDT(-0500)] <colinclark> i.e. they're flat

[16:24:27 CDT(-0500)] <colinclark> they have some unique identifier that identifies them as "some term"

[16:24:50 CDT(-0500)] <colinclark> i.e. in the format Christophe has written out for Nitesh

[16:25:10 CDT(-0500)] <colinclark> We will assume that the Common Terms Registry defines some set of conventions for how terms are "named"

[16:25:13 CDT(-0500)] <Bosmon> Yes

[16:25:19 CDT(-0500)] <colinclark> like 'em or not, I think this is pragmatic:

[16:25:33 CDT(-0500)] <Bosmon> In the ultimately iterated form of this insanity, these "names" will simply consist of a bunch of hex digits forming a GUID : P

[16:25:40 CDT(-0500)] <colinclark>

[16:25:53 CDT(-0500)] <Bosmon> Since clearly we will in the end one day run out of distinct and unique "terms" to form the left hand side

[16:26:20 CDT(-0500)] <colinclark> 1. There is a root that represents "the registry in which these are housed" (while many imagine that there is only "One CTR to rule them all", we may as well architect for many)

[16:27:08 CDT(-0500)] <colinclark> 2. There is a namespace distinguishing the "domain to which the term belongs" (i.e. "common" or "<insert your application id here>")

[16:27:38 CDT(-0500)] <colinclark> 3. The term has a name that actually means something

[16:28:04 CDT(-0500)] <colinclark> I've intentionally omitted one practically from our current "term URIs"

[16:28:26 CDT(-0500)] <colinclark> the portion of the hierarchy that distinguishes between common and application-specific terms

[16:28:46 CDT(-0500)] <colinclark> only because I need to think through what the consequences are of promoting a term from app-specific to common

[16:29:34 CDT(-0500)] <colinclark> If it were as simple as "this term is now designated common," we presumably wouldn't want to have to change the term's URI just for this case

[16:29:39 CDT(-0500)] <colinclark> anyway

[16:29:49 CDT(-0500)] <colinclark> term id, value

[16:30:11 CDT(-0500)] <colinclark> So then what's the meaning of the ontologization process?

[16:30:25 CDT(-0500)] <Bosmon> colinclark - which process in particular?

[16:30:31 CDT(-0500)] <Bosmon> Or rather - whose, and when?

[16:30:47 CDT(-0500)] <colinclark> I was thinking in general, to begin with

[16:31:09 CDT(-0500)] <colinclark> Despite Kasper's protestations, I think we've come to the point where we agree that even flatness is a kind of ontology

[16:31:16 CDT(-0500)] <Bosmon> It is