fluid-work IRC Logs-2013-09-11

[08:39:26 CDT(-0500)] <jhung> Justin_o, michelled: I was wondering if we can remove the Completed tasks from the Discovery Tool iteration plan wiki page?

[08:40:36 CDT(-0500)] <Justin_o> jhung: we are keeping around the the completed tasks that haven't yet been merged into the gpii repo

[08:40:45 CDT(-0500)] <Justin_o> that way we can keep track of what's missing from there

[08:40:52 CDT(-0500)] <jhung> Justin_o: ok sounds good.

[08:41:22 CDT(-0500)] <Justin_o> jhung: although some of these may have not been updated as we have recently sent a pull request to them.. i'll try to clean it up today

[08:41:38 CDT(-0500)] <jhung> Justin_o: I assume the latest jiras have not been added to the page yet? I don't see them...

[08:42:53 CDT(-0500)] <Justin_o> amilchev: looked into your issue a bit more yesterday and talked with cindyli and Bosmon about it.. for now i think you'll have to go with a single template that is combined ahead of time. cindyli and I will look into tackling the issue of complex panels. we'll start this by attempting to create a grade that can merge templates together ahead of rendering.

[08:43:24 CDT(-0500)] <Justin_o> jhung: no not yet.. i think we were waiting on michelled to check in with jessm about some things

[08:43:49 CDT(-0500)] <jhung> ok got it.

[08:46:27 CDT(-0500)] <michelled> jhung: you can add those new JIRAs to the page - the ones we said we would try to complete

[08:46:45 CDT(-0500)] <jhung> michelled: sure.

[08:46:47 CDT(-0500)] <michelled> we might shift to a quick sprint on Dani's tool - I'll try to figure that out today

[08:50:09 CDT(-0500)] <Justin_o> jhung: i updated the discovery tool iteration plan page

[08:50:15 CDT(-0500)] <Justin_o> removed the completed tasks

[08:50:41 CDT(-0500)] <jhung> Justin_o: great thanks. I'll put those jiras in now,

[08:51:26 CDT(-0500)] <Justin_o> jhung: thanks

[11:37:56 CDT(-0500)] <colinclark> yzen, Bosmon: So do we agree that we've got two somewhat different activities that Flow Manager can accomplish? 1. Stateful, device-specific configuration and 2. Stateless transformation of user preferences to settings for a particular "application" (i.e. web app or other remote service)

[11:38:08 CDT(-0500)] <colinclark> #2, in effect, is a subset of what is done as part of #1, I think

[11:38:42 CDT(-0500)] <Bosmon> That seems correct

[11:38:47 CDT(-0500)] <yzen> yes

[11:38:55 CDT(-0500)] <Bosmon> I wonder how the two activities are related in time and scope

[11:39:37 CDT(-0500)] <colinclark> I'd like to imagine that #2 is called repeatedly as part of the work of #1, and its results are then operated on directly.

[11:39:59 CDT(-0500)] <colinclark> I mean, I'm genuinely hopeful that #1 is a true subset

[11:40:22 CDT(-0500)] <colinclark> but I suspect some refactoring will have to happen

[11:43:12 CDT(-0500)] <colinclark> So my first proposal for the REST API for #2 is this: GET http://flow.gpii.net/token/<xyz>/settings/<app-id>

[11:43:23 CDT(-0500)] <colinclark> or one might argue for the ability to specify a set of application IDs

[11:49:15 CDT(-0500)] <yzen> colinclark: i was thinking that if settings/<app-id> is not present the whole set is returned

[11:49:42 CDT(-0500)] <colinclark> the preference set is returned, unmodified?

[11:51:01 CDT(-0500)] <yzen> colinclark: well not the preference set but the matched solutions and settings based on the user token id

[11:51:25 CDT(-0500)] <colinclark> what solutions would be matched in the case of a cloud-based flow manager? Can you elaborate?

[11:51:27 CDT(-0500)] <yzen> colinclark: sort of what i described on the wiki

[11:51:42 CDT(-0500)] <yzen> colinclark: so currently you can POST with device data

[11:51:48 CDT(-0500)] <colinclark> ah

[11:51:50 CDT(-0500)] <colinclark> curious

[11:52:19 CDT(-0500)] <Justin_o> Bosmon: when you have time, can you look at this jira http://issues.fluidproject.org/browse/FLUID-5131

[11:52:23 CDT(-0500)] <colinclark> I suppose this is a legitimate third activity

[11:52:38 CDT(-0500)] <colinclark> we should talk this through, it's fascinating

[11:52:49 CDT(-0500)] <Justin_o> Bosmon: it's for the work that we talked about in the channel yesterday.. does it sound right?

[11:54:00 CDT(-0500)] <Bosmon> Justin_o - it sounds right in outline, but needs to be fleshed out with a detailed implementation strategy

[11:55:41 CDT(-0500)] <Justin_o> Bosmon: thanks.. do you have time for some questions about that detail implementation strategy

[11:55:43 CDT(-0500)] <Justin_o> ?

[11:55:52 CDT(-0500)] <Bosmon> Justin_o - in a bit... still on a GPII call

[11:56:10 CDT(-0500)] <Justin_o> Bosmon: okay.. please let cindyli and I know when you are free

[12:02:13 CDT(-0500)] <yzen> so colinclark, Bosmon we have this API at the moment:

[12:02:14 CDT(-0500)]

[12:02:16 CDT(-0500)]

[12:02:38 CDT(-0500)] <colinclark> yup

[12:02:48 CDT(-0500)] <yzen> the one that was added already is:

[12:02:58 CDT(-0500)] <colinclark> which is only meaningful for a local, stageful Flow Manager

[12:03:05 CDT(-0500)] <yzen> yes

[12:03:17 CDT(-0500)]

[12:03:32 CDT(-0500)] <colinclark> Two issues with this one

[12:03:47 CDT(-0500)] <colinclark> I'm not sure the semantics of this action are indeed suitable for a POST

[12:03:56 CDT(-0500)] <colinclark> since presumably we don't actually change any server-side state

[12:04:19 CDT(-0500)] <colinclark> and thus, relatedly, it's probably not a "login" action

[12:04:20 CDT(-0500)] <colinclark> otherwise, I think this is reasonable

[12:04:26 CDT(-0500)] <colinclark> let's just think about what it actually is

[12:04:30 CDT(-0500)] <Bosmon> Yes

[12:04:32 CDT(-0500)] <yzen> yes

[12:04:33 CDT(-0500)] <Bosmon> What actually is it?

[12:04:37 CDT(-0500)] <Bosmon> And why isn't it the other way round?

[12:04:55 CDT(-0500)] <yzen> Bosmon: what is ?

[12:04:57 CDT(-0500)] <colinclark> Other way around how?

[12:05:13 CDT(-0500)] <Bosmon> Why is it not a GET which returns the payload, rather than a POST which accepts it?

[12:05:44 CDT(-0500)] <colinclark> I need to clarify...

[12:05:54 CDT(-0500)] <colinclark> A "GET which returns" which payload, specifically?

[12:06:04 CDT(-0500)] <Bosmon> The same one that is currently accepted by the POST

[12:06:20 CDT(-0500)] <Bosmon> And, being the way it is, WHEN exactly during the lifecycle do we expect it to be called?

[12:06:23 CDT(-0500)] <Bosmon> And what happens if it isn't

[12:07:01 CDT(-0500)] <colinclark> I'm slightly confused now

[12:07:09 CDT(-0500)] <Bosmon> That's good

[12:07:13 CDT(-0500)] <colinclark> So if we have three different actions on the Flow Manager

[12:07:14 CDT(-0500)] <Bosmon> This is "confusion of the kind we want" : P

[12:07:20 CDT(-0500)] <colinclark> yes

[12:07:39 CDT(-0500)] <colinclark> 1. Something stateful that does something to configure a particular device on which the Flow Manager is installed

[12:07:49 CDT(-0500)] <colinclark> This one is actually the weirdest case, but it might not look weird because it's all we've got

[12:08:39 CDT(-0500)] <colinclark> 2. Something stateless that, given a user token and a JSON payload describing a "remote device," returns (I think) a full "Lifecycle Specification"

[12:08:58 CDT(-0500)] <colinclark> 3. Something stateless that, given a user token and a particular application ID, produces a transformed, filtered set of settings for that application

[12:09:06 CDT(-0500)] <colinclark> I believe that #3 is what a web app needs

[12:09:24 CDT(-0500)] <colinclark> I think #2 is probably just there for consistency, but perhaps you can describe more, yzen

[12:09:48 CDT(-0500)] <yzen> colinclark: for some reason i feel like 3 is a subset of 2

[12:09:58 CDT(-0500)] <colinclark> Indeed

[12:10:16 CDT(-0500)] <colinclark> As far as I can tell, #3 is a subset of #2, which is a subset of #1

[12:10:23 CDT(-0500)] <Bosmon> !

[12:10:31 CDT(-0500)] <Bosmon> What do you mean by "is a subset of"

[12:10:37 CDT(-0500)] <colinclark> Well, I guess that's not entirely true

[12:10:44 CDT(-0500)] <Bosmon> And can you explain how something stateful can be a subset of something stateless : P

[12:10:52 CDT(-0500)] <colinclark> I'm not

[12:11:41 CDT(-0500)] <colinclark> The stateful action is composed of several of the stateless actions, plus some other stateful ones

[12:12:00 CDT(-0500)] <yzen> well

[12:12:07 CDT(-0500)] <yzen> lifecycle manager now a separate server

[12:12:12 CDT(-0500)] <colinclark> I believe in this case "subset of" means "This action is done as part of a larger collection of actions"

[12:12:17 CDT(-0500)] <yzen> so flow manager is not stateful at all

[12:12:24 CDT(-0500)] <colinclark> that's nice

[12:12:29 CDT(-0500)] <colinclark> that's a very good start

[12:13:14 CDT(-0500)] <colinclark> So, what does #2 do with the device information, yzen?

[12:13:58 CDT(-0500)] <yzen> colinclark: well that relates to the earlier issue i was talking to you about: the cloud based flow manager has no access to the device reporter to combine its output with the user preference set to send it to match maker

[12:14:09 CDT(-0500)] <yzen> in order to match anything we need that device payload

[12:14:21 CDT(-0500)] <colinclark> Sure, that makes sense

[12:14:45 CDT(-0500)] <colinclark> my first point here is that this is, for most clients of the cloud-based flow manager, irrelevant

[12:15:08 CDT(-0500)] <colinclark> So, we really do need to split this up into "what functionality will each of these 'services' provide?"

[12:15:33 CDT(-0500)] <colinclark> In the first case, we're talking about the kind of functionality we're familiar with--setting up an actual device that is "right here" on the local device where the flow manager is installed

[12:15:40 CDT(-0500)] <colinclark> #2 is like a variation on that

[12:16:42 CDT(-0500)] <colinclark> I think you're saying "in cases where the flow manager isn't on the local device there would be some other thing that was on the local device, which would invoke the cloud based flow manager, passing it a device specification and expecting back a full lifecycle specification."

[12:16:45 CDT(-0500)] <yzen> colinclark: sure well my thinking was that the web app id and anything else relevant "is" that device info

[12:16:48 CDT(-0500)] <colinclark> is that correct? Is that the use case you're thinking of?

[12:17:02 CDT(-0500)] <colinclark> I'm not sure it is, yzen

[12:17:44 CDT(-0500)] <yzen> colinclark: yes that's the second use case you described

[12:17:46 CDT(-0500)] <colinclark> Since web applications are themselves applications that may need to be contextualized by "device" (i.e. platform)

[12:17:52 CDT(-0500)] <colinclark> though to a significantly lesser extent

[12:18:11 CDT(-0500)] <Justin_o> Bosmon: quick question.. is there a way to update the view of a renderer component whose model is changed programmatically without calling refreshView. For example, if i render out a checkbox.

[12:19:17 CDT(-0500)] <colinclark> I guess your point is that a "Device specification" includes both information about OS, etc. as well as a list of relevant application IDs, yzen?

[12:19:28 CDT(-0500)] <yzen> colinclark: yes

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

[12:19:36 CDT(-0500)] <colinclark> I think I might be starting to buyt hat

[12:19:55 CDT(-0500)] <colinclark> but it still wouldn't be a POST request

[12:20:07 CDT(-0500)] <yzen> colinclark: what would you suggest then ?

[12:20:23 CDT(-0500)] <colinclark> A GET

[12:20:41 CDT(-0500)] <yzen> colinclark: would you give an example of such request ?

[12:21:11 CDT(-0500)] <colinclark> I imagine we'll have to use a query parameter

[12:21:21 CDT(-0500)] <colinclark> and compact our JSON payload

[12:22:06 CDT(-0500)] <yzen> colinclark: yes i was thinking about that too

[12:23:05 CDT(-0500)] <colinclark> I think the criteria for GET vs. POST should be pretty clear for the Flow Manager

[12:23:11 CDT(-0500)] <colinclark> i.e. "does it modify server state?"

[12:27:44 CDT(-0500)] <yzen> colinclark: ya I'm pretty comfortable with that , just was not sure if everyone's comfortable with sticking everything into the url

[12:28:38 CDT(-0500)] <colinclark> Yes, I'm okay with it

[12:29:18 CDT(-0500)]

[12:29:34 CDT(-0500)] <yzen> Bosmon: ^

[12:29:35 CDT(-0500)] <colinclark> yeah, that's ok

[12:29:49 CDT(-0500)] <colinclark> So we still have to clarify what comes out the other end

[12:30:27 CDT(-0500)] <colinclark> If I'm Facebook, do I want a big lifecycle specification?

[12:31:02 CDT(-0500)] <colinclark> I imagine I just want a JSON object containing some setting names and some values

[12:32:27 CDT(-0500)] <yzen> colinclark: well it depends on many things afaik , what is stored in the solutions registry, output of the matchmaker etc

[12:32:58 CDT(-0500)] <colinclark> how so?

[12:34:40 CDT(-0500)] <yzen> colinclark: would you expect Facebook entry to be in the solutions registry ?

[12:36:02 CDT(-0500)] <yzen> or rather

[12:36:35 CDT(-0500)] <yzen> would you expect (when faceboook requests something ) the flow manger to communicate to matchmaker?

[12:43:10 CDT(-0500)] <colinclark> I do think Facebook would be an entry in the Solutions Registry, yes

[12:44:18 CDT(-0500)] <colinclark> and I think it's quite possible that when Facebook requests something, the Flow Manager will need to delegate to a matchmaker, yes

[12:44:28 CDT(-0500)] <colinclark> it largely depends on what a Matchmaker actually bothers to do

[12:44:46 CDT(-0500)] <colinclark> I suspect that no current Matchmaker could meaningfully contribute anything to Facebook's workflow

[12:44:51 CDT(-0500)] <colinclark> but can you think of some examples of it?

[12:45:23 CDT(-0500)] <yzen> colinclark: the question is, whether there's another step (different from a request to lifecycle manager) or it returns the matchmaker output to the client (Facebook)

[12:45:44 CDT(-0500)] <colinclark> Remind me again what the nature of the Matchmaker's output is?

[12:45:54 CDT(-0500)] <colinclark> Do we have an example posted somewhere?

[12:46:02 CDT(-0500)] <yzen> colinclark: Facebook can probably make use of some of the common prefs

[12:46:11 CDT(-0500)] <yzen> i think so one sec

[12:47:08 CDT(-0500)] <yzen> http://pastie.org/8317600

[12:47:45 CDT(-0500)] <yzen> colinclark: i can see how this is not very helpful

[12:47:49 CDT(-0500)] <colinclark> no

[12:47:53 CDT(-0500)] <colinclark> not at all, for facebook

[12:51:36 CDT(-0500)] <yzen> colinclark: so we have these sections in there : lifecycleManager, settingsHandlers, settingsHandlers.settings

[12:54:18 CDT(-0500)] <colinclark> For Facebook, I suspect all we will ever want to share is the settingsHnadlers.settings part

[12:54:24 CDT(-0500)] <colinclark> It may well be that the Matchmaker will have some say over what goes into that

[12:58:27 CDT(-0500)] <yzen> right

[13:32:08 CDT(-0500)] <colinclark> Justin_o: Are we rocking the community meeting?

[13:33:09 CDT(-0500)] <Justin_o> colinclark: yep.. are you guys all done with your gpii meeting now?

[13:33:14 CDT(-0500)] <colinclark> yup

[13:33:18 CDT(-0500)] <Justin_o> okay

[13:33:50 CDT(-0500)] <Justin_o> fluid-everyone: please let me know if you'd like to join the community meeting today. I think we'll do it all over Skype today. The topic will be on planning the next infusion release.

[13:34:18 CDT(-0500)] <colinclark> me me

[13:34:33 CDT(-0500)] <michelled> me too!

[13:35:49 CDT(-0500)] <colinclark> I'm sure Bosmon wants to join, but he may have drifted off for a bit

[13:36:11 CDT(-0500)] <Justin_o> colinclark: okay

[13:36:23 CDT(-0500)] <Justin_o> fluid-everyone: would anyone else like to join?

[13:42:07 CDT(-0500)] <jhernandez> sgithens: JFYI, just updated https://github.com/GPII/android/pull/1

[13:44:55 CDT(-0500)] <sgithens> jhernandez: Thanks! I'll pull in your readme and source.dir change tonight.

[13:48:12 CDT(-0500)] <jhernandez> sgithens: thanks to you!!

[14:54:23 CDT(-0500)] <Justin_o> colinclark: here's some examples of lots of listeners and an invoker, but most of them are thisist https://github.com/fluid-project/prefsEditors/blob/master/src/discoveryTool/js/DiscoveryTool.js#L880-L935

[15:08:10 CDT(-0500)] <colinclark> thanks!