fluid-tech IRC Logs-2012-09-14

[15:32:19 CDT(-0500)] <yura> hi colinclark, do you have a moment to chat here about some concepts in GPII ?

[15:32:27 CDT(-0500)] <colinclark> go of rit

[15:33:05 CDT(-0500)] <yura> i m starting to take a look at tasks related to supporting multiple matchmakers

[15:33:47 CDT(-0500)] <yura> and i trying to build a mental model of how this sort of thing should be strutured

[15:34:15 CDT(-0500)] <yura> in the new architecture/configuration

[15:34:32 CDT(-0500)] <yura> flow manager only deals with the matchmaker data source

[15:35:52 CDT(-0500)] <yura> and matchmaker (to the outside world) is presented as a node app that handles requests to a certain path

[15:36:23 CDT(-0500)] <yura> requests to /match

[15:37:05 CDT(-0500)] <yura> with specific payload that contains info about device (id and solutions) + preferences

[15:37:13 CDT(-0500)] <yura> so i guess my question is

[15:37:52 CDT(-0500)] <yura> does this "support" for multiple matchmaker belong to the level of data sources or to the level, internal to the matchmaker itself

[15:37:57 CDT(-0500)] <yura> ?

[15:43:20 CDT(-0500)] <yura> my guess is that for configuration purposes it would be more maintainable to have it internal to the match maker

[15:43:58 CDT(-0500)] <yura> also otherwise there would be a missing component in the architecture that would need to be responsible for making sense of the results from the matchmakers

[15:48:22 CDT(-0500)] <yura> i guess the strategy approach is what I should look at

[15:52:24 CDT(-0500)] <colinclark> oh hi

[15:52:25 CDT(-0500)] <colinclark>

[15:53:07 CDT(-0500)] <colinclark> I'm not sure I fully understand the distinction between the two scenarios

[15:53:29 CDT(-0500)] <yura> sure ill try to draw it here

[15:53:48 CDT(-0500)] <yura> flowManager - has -> matchMakerDataSource

[15:54:21 CDT(-0500)] <yura> matchmaker is a standalone node app just like flowManager is

[15:54:36 CDT(-0500)] <yura> so one communicates to the other through the data source

[15:55:17 CDT(-0500)] <yura> so you can see how flowManager could potentially communicate to multiple matchmakers this way

[15:55:35 CDT(-0500)] <yura> where the multiplicity would be external to the matchmaker itself

[15:56:03 CDT(-0500)] <yura> but i guess the current implementation sketched out a "strategy" approach

[15:56:09 CDT(-0500)] <yura> and a single matchmaker

[15:56:54 CDT(-0500)] <yura> which the more i think about it is a sounds approach, since match maker itself becomes that component that knows how to make sense of the results from executing multiple strategies

[15:58:17 CDT(-0500)] <yura> not sure if i m making any sense