[Architecture] Ensuring the statistical matchmaker works before Luxembourg

Kasper Markus kasper at markus.dk
Wed Jan 14 04:22:53 EST 2015

Hi Andy,

There is nothing in the system that allows identifying the device by ID 
and I think we're too late in attempting to implementing it seeing how 
it's less than 1 week until we're live in Luxembourg. We have talked 
about the ability to manually set contexts via the PCP, but that was 
never in scope for the review (and wouldn't have worked out in this case 
anyway, as the PCP in it's current shape wouldn't work on DTV nor Kiosk).

I think the idea of making the SMM default might be the best option - 
but this does mean that you would need to ensure that the SMM works in 
/all the scenarios/ where we need matchmaking and SMM isn't specifically 
set as active (ie. when demoing the PMT, security, etc). In either case, 
we need to find a solution to this as soon as possible - the reason for 
preaching early integration for the past 6 months is to avoid being in 
situations like this 1 week ahead of the review...


On 1/13/15 10:40 PM, Andreas Stiegler wrote:
> Here is an example on how it should look or the dispatcher, but we 
> need respective conditions.
> https://www.dropbox.com/s/5i39u0yu59vkmyf/vladimir.json?dl=0
> Sorry for that. My information was that we manually set those context 
> blobs to be always active (similar to the GPII-Default) for the sake 
> of the review. Hence the context desc.
> Best regards,
> Andy
> *From:*architecture-bounces at lists.gpii.net 
> [mailto:architecture-bounces at lists.gpii.net] *On Behalf Of *Andreas 
> Stiegler
> *Sent:* Tuesday, January 13, 2015 10:26 PM
> *To:* 'Kasper Markus'
> *Cc:* architecture at lists.gpii.net
> *Subject:* Re: [Architecture] Ensuring the statistical matchmaker 
> works before Luxembourg
> Heyho Kasper,
> Oh, I’ve been  told that we would manually set that those context 
> blobs are active. If not, we should add conditions to those two blops 
> identifying that we are on the dtv or the vending machine. I sadly 
> don’t know how we could tell that (and it somehow spoils the idea of 
> those two scenarios with him not having any pref set entries for 
> them). If there are conditions with something like “device ID” or so, 
> that should do.
> Other option: make the SMM default and add dispatcher overrides for 
> the RBMM, but that would requiring altering the conditions and context 
> blobs in the vlad profile, as then gpii-default would have to be SMM.
> I think we should go with the first option: a condition for device-id 
> or something equivalent that allows us to tell that we are on the DTV 
> or the vending machine. If somebody could add that to those two 
> context blobs along with a priority, all should be fine.
> The two context blobs just serve the purpose of dispatching the call 
> to the SMM, they are not required in any other regard.
> Best regards,
> Andy
> *From:*Kasper Markus [mailto:kasper at markus.dk]
> *Sent:* Tuesday, January 13, 2015 9:21 PM
> *To:* Andreas Stiegler
> *Cc:* architecture at lists.gpii.net <mailto:architecture at lists.gpii.net>
> *Subject:* Re: Ensuring the statistical matchmaker works before Luxembourg
> Hi Andy,
> Thanks for your reply!
> The one thing I'm still not quite understanding is the "log in with 
> the pref set and the respective context active". The decision of the 
> active context is up to the minimatchmaker and based on the 
> 'condition' blocks along with any priority on the context blocks. I 
> might be missing something obvious, but I just wanted to make sure 
> that this will work with Andres' work merged in as well.
> Good luck on your Glasgow lectures,
> Cheers,
> ~Kasper
> On 1/13/15 3:00 PM, Andreas Stiegler wrote:
>     Hi Kasper,
>     The blocks in the pref set are only to ensure that the SMM I used
>     (given the dispatcher is included in the Luxemburg version).
>     The idea behind those two SMM scenarios is, that both are
>     scenarios where vlad encounters devices that he never used before
>     (ticket machine, hotel screen), but were used by many other people
>     already. So what the SMM does is searching through its database
>     for users that have similarity to the other settings that vlad
>     used in the past and infer settings for it (and magically, our
>     training data for the review covers both the vending machine and
>     the dtv well).
>     We did tests with the SMM here covering both scenarios. So unless
>     vlads pref set changed, all should be fine. We were never able to
>     test it with the actual vending machine or screen hardware of course.
>     Testing should be rather simple as the SMM is being deployed on
>     the IDRC cloud. Once that’s done you should just be able log in
>     with the pref set and the respective context active. The
>     dispatcher will forward to the SMM and apply the settings.
>     The whole call chain works and was tested over here, but I don’t
>     know if the dispatcher is already in.
>     If you want to install the SMM locally, just go to
>     https://github.com/REMEXLabs/GPII-Statistical-Matchmaker , and
>     follow the instructions (npm install and delete duplicate infusion
>     inclues).
>     I’ll only be available very sporadically this week, as I’m giving
>     guest lectures in Glasgow.
>     Best regards,
>     Andy
>     *From:*Kasper Markus [mailto:kasper at markus.dk]
>     *Sent:* Tuesday, January 13, 2015 11:45 AM
>     *To:* Andreas Stiegler
>     *Cc:* architecture at lists.gpii.net
>     <mailto:architecture at lists.gpii.net> Architecture
>     *Subject:* Ensuring the statistical matchmaker works before Luxembourg
>     Hi Andy,
>     Hope you've had a nice christmas and new year!
>     We're getting scarily close to the review meeting and in that
>     connection I have some questions/requests for you:
>       * For the vladimir scenario - there are some blocks describing
>         that the STMM should be used
>         (https://github.com/kaspermarkus/universal/blob/review3/testData/preferences/vladimir.json#L76-L87).
>         These are modeled as context blocks, but it's not clear to me
>         how the system would evaluate these blocks to be active..
>         Could you clarify this?
>       * We have not yet tested any of the ST MM scenarios and it would
>         be good to have done so as soon as possible. Since the ST MM
>         is used in the scenarios of the Kiosk and DTV, the only people
>         really able to test it properly pre-luxembourg would be Jasmin
>         and Thomas respectively. So, would you be able to write up
>         instructions to them on how to set everything up, deploy the
>         ST MM and run the tests so they can try it out and we can find
>         any potential issues before meeting up in luxembourg?
>     Cheers,
>     ~Kasper

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20150114/a9be9e1d/attachment-0001.html>

More information about the Architecture mailing list