fluid-tech IRC Logs-2013-09-05

[11:37:26 CDT(-0500)] <yzen> colinclark, kasparnet I wanted to run something by you

[11:37:42 CDT(-0500)] <colinclark> ok

[11:39:18 CDT(-0500)] <yzen> so in case of the cloud based flow manager , how would it communicate to the device reporter ?

[11:39:30 CDT(-0500)] <yzen> my understanding is that the device reporter is on the client

[11:39:58 CDT(-0500)] <yzen> the user would attempt to log in to the cloud based matchmaker similarly to how it already does e.g. with a token

[11:40:22 CDT(-0500)] <yzen> any thoughts on how the flow manager would get the device information in order to be able to communicate to the match maker

[11:40:27 CDT(-0500)] <yzen> sorry if I'm missing smth bth

[11:40:30 CDT(-0500)] <yzen> btw

[11:42:43 CDT(-0500)] <yzen> colinclark: kasparnet ^

[11:43:35 CDT(-0500)] <colinclark> Your question is a good one, yzen.

[11:44:16 CDT(-0500)] <colinclark> For our first iteration, I think we're going to assume that the device's capabilities aren't particularly relevant in this scenario

[11:44:23 CDT(-0500)] <colinclark> since a web app is "device neutral"

[11:44:43 CDT(-0500)] <colinclark> in reality, this is pretty naive.

[11:44:59 CDT(-0500)] <yzen> colinclark: the thing is that the match maker is not device neutral afaik

[11:45:19 CDT(-0500)] <colinclark> In this context, I think it has to

[11:45:48 CDT(-0500)] <colinclark> I remember on one of the evenings in the San Diego zen house we talked about how we would need some connection, perhaps via a browser plugin, with the native device

[11:46:02 CDT(-0500)] <colinclark> to avoid cases, for example, where we would make the text size too large because it had been "doubly applied"

[11:46:18 CDT(-0500)] <colinclark> Presumably for now, however, there should be a "device" that represents the web

[11:46:34 CDT(-0500)] <kasparnet> yeah, I think that makes sense as well

[11:46:45 CDT(-0500)] <yzen> colinclark: so i was thinking web sockets?

[11:46:56 CDT(-0500)] <colinclark> yzen: Yes, it's a pretty good possibility

[11:47:15 CDT(-0500)] <colinclark> Having played now a fair bit with my Leap Motion controller, I'm realizing how smooth web sockets can be for this kind of use case

[11:47:26 CDT(-0500)] <colinclark> If you can look past the huge potential security risks, anyway

[11:47:28 CDT(-0500)] <colinclark>

[11:47:38 CDT(-0500)] <colinclark> I think it might be viable to have some basic "device" information synthesized in the browser

[11:47:43 CDT(-0500)] <colinclark> and sent along to the web-based Flow Manager

[11:47:58 CDT(-0500)] <colinclark> i.e. at least to pass along things like what browser the user is on

[11:47:59 CDT(-0500)] <colinclark> etc.

[11:48:48 CDT(-0500)] <yzen> colinclark: well, is the idea behind the cloud based match maker to work with web solutions ?

[11:49:01 CDT(-0500)] <colinclark> yes

[11:49:09 CDT(-0500)] <colinclark> That is our first use case

[11:49:23 CDT(-0500)] <colinclark> we'll want to expand it to work for things like the Java "dumb" phones

[11:49:52 CDT(-0500)] <colinclark> I suspect, ultimately, that we'll continue with a model where the Flow Manager will reside locally for most desktop/smartphone use cases

[11:50:05 CDT(-0500)] <colinclark> but I'm not averse to other approaches

[11:50:09 CDT(-0500)] <colinclark> kasparnet, what's your impression?

[11:50:10 CDT(-0500)] <yzen> so in order to have the browser information the user has to make the request directly, or the app has to pass that information to the flow manager, as far as i understand in most cases the app will make the request on behalf of the user ?

[11:50:32 CDT(-0500)] <colinclark> I think the latter case, yes

[11:51:03 CDT(-0500)] <kasparnet> yeah, the latter

[11:51:55 CDT(-0500)] <kasparnet> and I agree, in most cases we want to (for now) assume that those devices capable of it (ie. everything but browser based solutions, smarthouses, bank app and javaphone) will run GPII locally

[11:52:23 CDT(-0500)] <colinclark> is this seeming sensible and viable, yzen?

[11:52:38 CDT(-0500)] <kasparnet> and I think it's sensible to have the app using the online flowmanager reporting the context/device in which it's being used

[11:53:06 CDT(-0500)] <yzen> well are we talking about the api change ?

[11:53:06 CDT(-0500)] <colinclark> We can make a little Node.js example for people to see or use

[11:53:15 CDT(-0500)] <colinclark> how so?

[11:53:38 CDT(-0500)] <yzen> e.g. user token + something like browser info ?

[11:53:43 CDT(-0500)] <yzen> when you mentioned sending it along

[11:53:52 CDT(-0500)] <colinclark> yes, I think that's the case

[11:54:35 CDT(-0500)] <colinclark> One can imagine that the web-based Flow Manager is a reconfiguration of the desktop-based Flow Manager's workflow

[11:54:53 CDT(-0500)] <yzen> yes

[11:54:55 CDT(-0500)] <colinclark> i.e. aggregating several steps of the flow into one and removing a few others

[11:57:48 CDT(-0500)] <colinclark> kasparnet: Just as a heads up that we're we're likely going to have a big GPII demo or two in October

[11:57:55 CDT(-0500)] <kasparnet> ok

[11:57:55 CDT(-0500)] <colinclark> focusing in particular on Windows platforms

[12:10:56 CDT(-0500)] <kasparnet> colinclark: thanks for the heads up

[12:11:18 CDT(-0500)] <kasparnet> it's gonna be nice to have some motivation to set up a nice demo config as well

[12:15:27 CDT(-0500)] <colinclark> and an installer

[12:15:35 CDT(-0500)] <colinclark> and all that polish

[16:02:23 CDT(-0500)] <Bosmon2> yzen.... what's the quickest way to get an npm-style git revision URL?

[16:57:15 CDT(-0500)] <yzen> #SHA

[16:57:19 CDT(-0500)] <yzen> or #branch