[Architecture] Integrating a new Matchmaker

Andreas Stiegler stiegler at hdm-stuttgart.de
Fri Jan 11 02:34:38 EST 2013


Heyho,

Sorry for my delayed response.
Yep, In the long run, I think I would favor interfacing a web service. That
could be the easiest way to deal with "heavy" match makers, that maintain
their own databases.
But no need to hurry. For now, the function-approach is fine. I will just
generate a json file from the statistical analysis program to be used by the
matchmaker. The datasets are quite small and static at the moment either way
:)

Best regards,
Andy

-----Original Message-----
From: Colin Clark [mailto:colinbdclark at gmail.com] 
Sent: Thursday, January 10, 2013 11:47 PM
To: Andreas Stiegler; Yura Zenevich; Kasper Markus
Cc: architecture at lists.gpii.net
Subject: Re: [Architecture] Integrating a new Matchmaker

Andy,

I'm guess that you're probably integrating a Lua-based web service, so
you're likely interested in the second approach that Yura mentioned. Is that
right?

Yura and Kasper, do you know if we have any documentation describing how to
configure a new remote Matchmaker service? If I remember, it's just a few
lines of configuration to change, but it's probably helpful to have a few
pointers into how/where this is done. I forget if we have any current
documentation about it?

Colin

On 2013-01-09, at 11:35 AM, Yura Zenevich <yura.zenevich at gmail.com> wrote:

> * The other approach would essentially involve swapping all of the
matchmaker component (although that means you would be loosing all of the
existing infrastructure that might be otherwise useful). The thing to worry
about here is the external matchmaker API. Matchmaker should support POST
requests with solutions and preferences information and should respond with
the matched solutions payload. This approach would be more involved and if
you decide to do it, let me know if you need any more pointers.

---
Colin Clark
http://fluidproject.org



More information about the Architecture mailing list