fluid-work IRC Logs-2013-09-18

[07:31:37 CDT(-0500)] <amilchev> Justin_o: hi

[07:31:49 CDT(-0500)] <Justin_o> amilchev: hello

[07:32:37 CDT(-0500)] <amilchev> Justin_o: tell me if you have time to explain how end-to-end connectivity could be managed

[07:33:36 CDT(-0500)] <amilchev> Justin_o: what I want is to pass the saved settings from the panel properly - as far as Evgeni told me, to define something like this https://github.com/tsakov/universal/blob/node-webkit/gpii/node_modules/personalControlPanel/src/content/deps/GPIIStore.js

[07:34:56 CDT(-0500)] <amilchev> Justin_o: is there anything other than defining the invokers "fetch" and "save"

[07:36:36 CDT(-0500)] <amilchev> I'll be here for three hours more, if any of this time interval is comfortable to you to help, please let me now

[07:37:21 CDT(-0500)] <Justin_o> amilchev: looking at it right now

[07:37:30 CDT(-0500)] <Justin_o> amilchev: here is where the store is defined in infusion https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/Store.js

[07:39:24 CDT(-0500)] <Justin_o> amilchev: so you could just create your own store with a base grade of dataSource and define the invokers for get and set

[07:42:20 CDT(-0500)] <Justin_o> amilchev: you wouldn't need to use the demands blocks though as in the example for infusion, to override get and set, you can just do that in the configuration by assigning a new function to the invokers.

[07:44:03 CDT(-0500)] <Justin_o> amilchev: if you are going to use the globalSettingStore though you will want to change the type from fluid.cookieStore to your new one

[07:46:07 CDT(-0500)] <Justin_o> amilchev: these are attached to the uiOptions through grade merging https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/UIOptions.js#L220-L235

[07:46:53 CDT(-0500)] <amilchev> Justin_o: should I define a static environment "gpii.pcp" and define the grade this way:

[07:46:53 CDT(-0500)] <amilchev> fluid.defaults("gpii.pcp.store",

[07:46:53 CDT(-0500)] <amilchev> gradeNames: ["fluid.uiOptions.dataSource", "autoInit"],

[07:46:53 CDT(-0500)] <amilchev> ...);

[07:47:07 CDT(-0500)] <amilchev> the component*

[07:49:49 CDT(-0500)] <Justin_o> amilchev: so it looks like the gpii.pcp static environment is there so that the demands block can be set to switch the type of store..

[07:50:17 CDT(-0500)] <amilchev> yes

[07:50:25 CDT(-0500)] <Justin_o> amilchev: you can avoid the demands block by creating your own version of fluid.globalSettingsStore and changing the type of settingsStore there to your new one.

[07:50:58 CDT(-0500)] <amilchev> Justin_o: ok

[07:51:19 CDT(-0500)] <Justin_o> then you'd pass in this new globalSettingsStore to your assembled uio by changing the type of its store subcomponent to your new globalSettingsStore

[07:51:54 CDT(-0500)] <Justin_o> amilchev: the defaults call you have above looks good

[07:54:00 CDT(-0500)] <amilchev> hmm so let me see if I got it:

[07:55:13 CDT(-0500)] <amilchev> Justin_o: I create my own component of grade name dataSource and there I override invokers get and set

[07:55:28 CDT(-0500)] <amilchev> and then

[07:57:29 CDT(-0500)] <amilchev> Justin_o: I create a component of grade name fluid.globalSettingsStore and this type https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/Store.js#L146 is the one that I just mentioned

[07:58:02 CDT(-0500)] <Justin_o> sounds good so far

[08:04:29 CDT(-0500)] <amilchev> Justin_o: how should functions get and set look like?

[08:05:17 CDT(-0500)]

[08:07:38 CDT(-0500)]

[08:07:56 CDT(-0500)] <Justin_o> amilchev: you can see that here https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/Store.js#L59

[08:08:07 CDT(-0500)] <Justin_o> https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/Store.js#L110-L113

[08:09:39 CDT(-0500)] <Justin_o> amilchev: you should probably maintain that external api.. so you can expect that someone calling your invoker will only be passing in the settings… any other arguments you'll likely need to be setting in your invoker setup and sourcing from somewhere else

[08:09:50 CDT(-0500)] <Justin_o> as per the example i just pasted

[08:22:31 CDT(-0500)] <amilchev> Justin_o: not sure what you tried to explain here.. if it is what "args" does with invokers, I know that ..

[08:22:59 CDT(-0500)] <Justin_o> amilchev: yes.. basically that..

[08:24:26 CDT(-0500)] <amilchev> Justin_o: I actually asked what should the two functions do, rather than how they would be called

[08:26:49 CDT(-0500)] <Justin_o> amilchev: okay… at a high level one sets which you can think of as save, and the other gets the values from the store.. at a lower level this will be highly dependent on where you are setting to and getting from.. cindyli is starting on some code to work with the GPII preference server, perhaps she could share that with you to give you some ideas

[08:27:28 CDT(-0500)] <amilchev> Justin_o: evgeni talked about something like https://github.com/tsakov/universal/blob/node-webkit/gpii/node_modules/personalControlPanel/src/content/deps/GPIIStore.js#L50-L56

[08:29:42 CDT(-0500)] <Justin_o> amilchev: having these things refer to http requests makes sense.. although i can't really comment on the URL structure/api needed for that

[08:30:28 CDT(-0500)] <cindyli> amilchev: the code I'm writing to get / set prefs from gpii server: https://github.com/cindyli/prefsEditors/compare/GPII-185

[08:33:43 CDT(-0500)] <cindyli> let me know if you have questions

[08:39:30 CDT(-0500)] <amilchev> cindyli: thanks, that looks helpful, let me start writing my own and see where questions will pop out

[08:39:44 CDT(-0500)] <cindyli> sure, amilchev

[09:18:23 CDT(-0500)]

[09:18:23 CDT(-0500)] <amilchev> what are the URLs for my GET and POST requests? Perhaps they depend on the token (for instance if user sammy is logged in, the url should be sth like .../sammy/update)?

[09:20:30 CDT(-0500)] <cindyli> amilchev: yes, it depends on the token. as i understand, with gpii, the url would always be …/sammy while "sammy" is the user token. there's no such thing as /sammy/update

[09:21:37 CDT(-0500)] <cindyli> Sending a GET request to the token url is to retrieve prefs while sending a POST request is to update

[09:22:56 CDT(-0500)] <amilchev> cindyli: oh, as far as "update" goes, I guess I keep being confused by the file Evgeni sent me https://github.com/tsakov/universal/blob/node-webkit/gpii/node_modules/personalControlPanel/src/content/deps/GPIIStore.js#L52

[09:22:57 CDT(-0500)] <cindyli> my script has 2 urls for setting and getting is only for testing purpose, in case we'd like to retrieve data from an actual user but not willing to update its data, in which case the save url can point to a test token

[09:23:46 CDT(-0500)] <cindyli> ah ha, i'm confused by that line too could it be pcp specific?

[09:24:48 CDT(-0500)] <amilchev> cindyli: I'm not sure, Evgeni told me to send the POST request to .../update

[09:25:48 CDT(-0500)] <cindyli> amilchev: we are talking about updating gpii prefs data, right? yzen might know better.

[09:26:23 CDT(-0500)] <yzen> amilchev: cindyli as far as i know the /update API is only defined in his branch

[09:26:42 CDT(-0500)] <cindyli> ah ok

[09:28:07 CDT(-0500)] <cindyli> seems depending on which branch your gpii server is built from, amilchev

[09:29:12 CDT(-0500)] <amilchev> cindyli: yzen: so the URL for the POST request should be localhost:8081/user/<<token>>/update

[09:29:25 CDT(-0500)] <yzen> i think so yes

[09:29:48 CDT(-0500)] <amilchev> ok

[09:47:26 CDT(-0500)] <Justin_o> michelled: i fixed the commit log for my GPII-202 pull request and showed the interaction to vjoanna. You can find the new pull request at https://github.com/fluid-project/prefsEditors/pull/48

[09:52:04 CDT(-0500)] <michelled> thx Justin_o

[09:56:29 CDT(-0500)] <colinclark> hey michelled and Justin_o, yzen wants to demonstrate the Discovery Tool in Portugal

[09:56:34 CDT(-0500)] <colinclark> which URL should he use?

[09:58:24 CDT(-0500)] <michelled> http://build.fluidproject.org/prefsEditors/demos/discoveryTool/

[10:00:55 CDT(-0500)] <colinclark> yzen: ^

[10:01:33 CDT(-0500)] <colinclark> you can talk about how the Preferences Framework provides the auto personalization tools a web app might want to provide for users

[10:03:54 CDT(-0500)] <yzen> colinclark: michelled thanks

[10:04:01 CDT(-0500)] <michelled> np

[10:04:07 CDT(-0500)] <yzen> colinclark: exactly my words

[10:04:11 CDT(-0500)] <colinclark> lol

[10:06:24 CDT(-0500)] <avtar> yzen: cindyli, Justin_o, and i were taking a look at switching dev environments for the preferences server over to production

[10:07:03 CDT(-0500)] <yzen> it is isn't it ?

[10:08:03 CDT(-0500)] <avtar> i searched around on the gpii wiki but i couldn't find instructions that users can follow to modify the test preferences https://github.com/GPII/universal/tree/master/testData/preferences so that they can be imported into couchdb

[10:09:08 CDT(-0500)] <avtar> is there a reason why the test preferences aren't formatted already to accommodate the couchdb api?

[10:11:19 CDT(-0500)] <yzen> avtar: as far as i know preferences.gpii.net runs with couch

[10:11:27 CDT(-0500)] <yzen> and you can add modify preferences sets

[10:11:27 CDT(-0500)] <avtar> it does

[10:14:42 CDT(-0500)] <avtar> yzen: i'm not sure i follow

[10:15:04 CDT(-0500)] <yzen> oh that

[10:15:10 CDT(-0500)] <avtar> if someone wants to test the preferences server using the production config

[10:15:25 CDT(-0500)] <yzen> avtar: yes this is very vague right now,

[10:15:34 CDT(-0500)] <avtar> ok

[10:15:46 CDT(-0500)] <yzen> as far as i know steve had a tool that we used to upload the records

[10:15:49 CDT(-0500)] <yzen> not sure if you did the same

[10:16:13 CDT(-0500)] <avtar> yzen

[10:16:15 CDT(-0500)] <avtar> oops

[10:16:45 CDT(-0500)] <avtar> we've been relying on backups of the couchdb data when new preference server instances need to be spun up

[10:17:24 CDT(-0500)] <avtar> so i was wondering why someone else, who doesn't have access to preferences.gpii.net backups, has to go through an extra step to modify the test preferences in order for them to be useful

[10:18:12 CDT(-0500)] <yzen> avtar: yes, there's work that needs to be done there, but i m not even sure we have a strategy for it

[10:23:10 CDT(-0500)] <avtar> yzen: ok

[10:23:52 CDT(-0500)] <avtar> i'll add a note to the configuration wiki page

[10:32:56 CDT(-0500)] <yzen> avtar: thanks

[11:17:12 CDT(-0500)] <michelled> colinclark: I just make a pull request that fixes the styling for the contrast panel in UIO https://github.com/fluid-project/infusion/pull/406

[11:17:21 CDT(-0500)] <michelled> it's part of the 4922 work

[11:18:57 CDT(-0500)] <michelled> hmmm… I guess the fast invoker fix means a bit of an API change. users will now have to specify when they expect an invoker to be dynamic.

[11:19:03 CDT(-0500)] <michelled> Justin_o, anastasiac ^

[11:20:16 CDT(-0500)] <Justin_o> michelled: it's unfortunate.. i guess we need to document this and explain when something will need to be dynamic or not. probably okay for the release though as IoC wasn't really production in 1.4

[11:24:04 CDT(-0500)] <colinclark> This is why I want to get 1.5 out and move on as soon as possible

[11:24:39 CDT(-0500)] <colinclark> we end up in these situations where we have to consider a weaker API in order to preserve backwards compatibility of features that were largely unused by third party developers

[11:24:46 CDT(-0500)] <colinclark> so I'm tempted to agree with Justin_o here

[11:25:06 CDT(-0500)] <colinclark> Certainly the semantics of the default configuration of an invoker have indeed changed, michelled

[11:25:11 CDT(-0500)] <colinclark> But it's split down the middle

[11:25:36 CDT(-0500)] <colinclark> presumably users would be equally pleased to get a 200x speed increase in their existing invokers, when they don't require dynamic evaluation of their arguments

[11:27:52 CDT(-0500)] <michelled> I agree that as long as we document this for 1.5 we are good

[11:28:01 CDT(-0500)] <michelled> the new invokers are certainly much shinier

[13:34:00 CDT(-0500)] <anastasiac> Justin_o, do you know why this was closed? http://issues.fluidproject.org/browse/FLUID-4434 The tests are still failing at http://build.fluidproject.org/infusion/tests/component-tests/uiOptions/html/CSSGenerator-test.html Am I running the wrong tests?

[13:35:35 CDT(-0500)] <Justin_o> anastasiac: that must be a new issue.. the one in the jira was caused by the location they were in.. i've tested these recently while working on UIO and they had been passing

[13:35:43 CDT(-0500)] <Justin_o> anastasiac: do they work locally for you?

[13:36:28 CDT(-0500)] <anastasiac> yes, Justin_o, they work locally for me (i.e. through localhost)

[13:37:23 CDT(-0500)] <anastasiac> Justin_o: I think we should reopen this one, no? the tests don't run on the build site. Or do we consider that acceptable?

[13:38:05 CDT(-0500)] <Justin_o> anastasiac: ah my mistake, the issue should be reopened.. the js files it tries to run are missing

[13:38:32 CDT(-0500)] <Justin_o> anastasiac: i had misread this as the test files were missing

[13:39:32 CDT(-0500)] <anastasiac> fluid-everyone, shall we gather for the community meeting? Toronto folks, in the collab room (donuts!!). Bosmon, Bosmon8, colinclark, will you be able to join us remotely for another docs sprint?

[13:39:56 CDT(-0500)] <Justin_o> anastasiac: i'm in.. please reserve me a donut

[13:44:17 CDT(-0500)] <colinclark> sadly I won't be able to join you for the sprint today

[13:44:32 CDT(-0500)] <colinclark> But rest assured I am writing a form of documentation nonetheless

[13:51:01 CDT(-0500)] <anastasiac> Justin_o, cindyli1, michelled, the planning page for today: http://wiki.fluidproject.org/display/fluid/Docs+Sprint+Planning

[14:18:36 CDT(-0500)] <Bosmon> Hi guys - sorry to miss the sprint beginning

[14:18:39 CDT(-0500)] <Bosmon> Is it still going on?

[14:18:41 CDT(-0500)] <Bosmon> Justin_o ^

[14:18:56 CDT(-0500)] <Justin_o> Bosmon: yes.. we'll pull you in

[14:19:04 CDT(-0500)] <Bosmon> Cheers!

[14:31:21 CDT(-0500)] <anastasiac> Bosmon: http://wiki.fluidproject.org/display/fluid/Docs+Sprint+Planning

[14:34:25 CDT(-0500)] <anastasiac> Bosmon: http://wiki.fluidproject.org/display/docs/IoCSS

[14:44:32 CDT(-0500)] <colinclark> Bosmon: I'm wondering if you can help me with a summary

[14:44:45 CDT(-0500)] <Bosmon> Hi colinclark

[14:44:47 CDT(-0500)] <colinclark> I'd like to make a list to use as a writing platform

[14:44:57 CDT(-0500)] <colinclark> Keeping in mind that my audience isn't particular technical

[14:45:14 CDT(-0500)] <colinclark> but I'm hoping you could help me summarize the "things we do" to enable an application to be personalizable

[14:45:22 CDT(-0500)] <colinclark> And I guess this happens at several layers

[14:45:31 CDT(-0500)] <colinclark> from how we create our CSS and markup down into more "substantial" concerns

[14:47:07 CDT(-0500)] <colinclark> So, to start, is there anything you'd highlight about how we handle the so-called "presentation layer" of a web application--i.e. its CSS and markup?

[14:49:47 CDT(-0500)] <Bosmon> Well, that's a good question...

[14:49:53 CDT(-0500)] <Bosmon> I'm struggling to think of anything very specific

[14:50:35 CDT(-0500)] <colinclark> ok

[14:50:39 CDT(-0500)] <Bosmon> Naturally there are the obvious good practices... of, for example, actually having a separate CSS file at all : P

[14:50:47 CDT(-0500)] <Bosmon> Can you give me a few hints about any angles you are thinking of?

[14:51:09 CDT(-0500)] <Bosmon> In general we aim to place as few constraints as possible on what designers may do with the CSS and markup layer

[14:51:37 CDT(-0500)] <Bosmon> And part of the upcoming rendering work would be targetted at removing some of the constraints that we currently do impose (for example, the need for extra <div>s in some places)

[14:51:58 CDT(-0500)] <colinclark> ok

[14:52:03 CDT(-0500)] <Bosmon> I guess the important thing is that we aim to "intensify" the existing good practice of binding onto the markup layer using stable selectors

[14:52:09 CDT(-0500)] <colinclark> I'm in a strange section of the document

[14:52:23 CDT(-0500)] <colinclark> that has just highlighted the lack of viability of the "transcoding" approach

[14:52:32 CDT(-0500)] <colinclark> i.e. after-the-fact transformation of web content

[14:52:43 CDT(-0500)] <Bosmon> In theory this is something that a good designer will do anyway, but if an application is to be radically reskinned in various ways, this system of "spines" operated by selectors which targets many different sets of markup need to be more secure than usual

[14:52:47 CDT(-0500)] <colinclark> And so I'm trying to steer the discussion to a more significant level

[14:53:01 CDT(-0500)] <colinclark> Here is the paragraph I've written so far

[14:53:12 CDT(-0500)] <colinclark> "In contrast to the pitfalls of after-the-fact transcoding, the PGA architecture emphasizes the importance of building applications from the beginning to be personalization-aware. This requires a different approach to software development. Instead of hardcoding a single user interface and underlying programming logic, personalizable applications need to support flexible connections between modular user interfaces and underlying services."

[14:53:25 CDT(-0500)] <Bosmon> ok

[14:53:33 CDT(-0500)] <colinclark> I utterly loathe the term "services" since it evokes a very enterprise-y conception of SOA

[14:53:45 CDT(-0500)] <Bosmon> I guess the "flexible connections" leads into the "stable selectors" discussion

[14:53:58 CDT(-0500)] <colinclark> ok

[14:54:50 CDT(-0500)] <Bosmon> And in theory, that "stable selectors" discussion then leads into the equivalent one for component trees

[14:56:23 CDT(-0500)] <colinclark> so keep going, in terms of the next level in application development

[14:57:04 CDT(-0500)] <Bosmon> At the next level in application development, these "stable names" are extended into the world of code, in terms of "well-known grade names and their well-known options"

[14:57:26 CDT(-0500)] <Bosmon> And the framework assists the developer in maintaining this stability by schemes such as grade merging and the IoCSS system

[14:57:41 CDT(-0500)] <Bosmon> Which allows ambitious refactorings to take place whilst maintaining stable grades names and options structures

[14:58:09 CDT(-0500)] <Bosmon> As well as allowing substantially different implementations to coexist under these same names

[15:01:06 CDT(-0500)] <colinclark> michelled, Justin_o: Do we have a list of all our current enactors somewhere?

[15:02:18 CDT(-0500)] <Justin_o> colinclark: i think just this https://github.com/fluid-project/infusion/blob/master/src/components/uiOptions/js/Enactors.js

[15:03:20 CDT(-0500)] <colinclark> thanks, Justin_o

[15:03:46 CDT(-0500)] <colinclark> so, I'm trying to figure out how to explain this notion of "stable grades" to a non-techy

[15:03:53 CDT(-0500)] <colinclark> I realize this is a challenge

[15:03:59 CDT(-0500)] <colinclark> but can you think of some examples of this in practice

[15:04:17 CDT(-0500)] <colinclark> or, if we have to stay abstract, describe what role a "stable name" plays?

[15:04:23 CDT(-0500)] <Bosmon> I guess all of the good examples would be from UIOptions

[15:04:46 CDT(-0500)] <Bosmon> For example, that ambitious refactoring that cindyli1 did last month, which removed an entire layer of containment from the component structure

[15:04:51 CDT(-0500)] <colinclark> I guess the point is that every "connection" between components is visible and configurable

[15:05:03 CDT(-0500)] <Bosmon> This is something that could never have been survived in a traditional OO system

[15:05:21 CDT(-0500)] <Bosmon> But in fact none of our APIs had to change

[15:05:50 CDT(-0500)] <Bosmon> Similar but more minor things occurred when I rewrote our "old components" into the IoC format

[15:07:24 CDT(-0500)] <Bosmon> With the current IoC system, it's possible to have i) APIs that aren't "flat" (that is, expose a recursive structure of reusable blocks) but which are nontheless ii) stable, but without iii) the user having to manually write "facade" code for bridging or brokering by hand

[15:08:09 CDT(-0500)] <Bosmon> Typically even flat, stable APIs were a challenge in previous systems

[15:08:25 CDT(-0500)] <colinclark> okay, so now can you connection this notion of "refactoring" to user personalization?

[15:08:30 CDT(-0500)] <Bosmon> Yes

[15:08:44 CDT(-0500)] <Bosmon> I guess you could say that this connection amounts to considering "stability over space, as well as stability over time"

[15:09:17 CDT(-0500)] <Bosmon> You could see that personalization is just another case of "multiple implementations coexisting harmoniously under the same options structure" as refactoring

[15:09:56 CDT(-0500)] <Bosmon> Certainly if the developer can't maintain the stability of their OWN artifacts for their own purposes, they could hardly commit to maintaining stability on behalf of changes required by their users

[15:10:08 CDT(-0500)] <Bosmon> So you could say that at a minimum, the one kind of stability is a prerequisite for the other