Today we're going to talk a bit about contexts and what wonderful things you can do with them.

Well, maybe not "Wall-E opening sequence" wonderful, but they sure come in handy to control what your agent is doing in an easy and trouble-free way. With the help of contexts you can separate clearly your routines according to any condition, without having to worry about micro-managing their scores or doing systematic checks.

We're going to take a closer look at a few different uses and related buddyscript features, from the very simple to... the wee bit advanced. Tomorrow we'll explore another use for them, and discuss public variables and performance issues.

Here is how, for example, you could make sure that only users on MSN get access to the activity window features:

context MSN_Only {out-of-context="0" in-context="100" condition="SYS.User.Service eq \"MSN\""}

// out-of-context: score adjustment for the queries inside the context that don't verify the condition (here,   0 = no match)

// in-context    : score adjustment for the queries inside the context that do verify the condition    (here, 100 = no adjustment)

start context MSN_Only

? Start the activity.

  - Sending you an invitation...

end context MSN_Only

 An interesting thing to note is that you don't have to end the context at the end of our file. If you were to start the context in a package, then every domain including this package, directly or indirectly, would be within that context and abide by its rules. So here you could have all domains related to Activity Window include this package, and be protected automatically.

  You could apply this principle to restrict certain features or queries based on any condition, like age, country, market, number of visits or what the user's high-score is at your quizz game.

You can also restrict access to the agent even though it's launched and live on Messenger, while it's in development or beta phase:

// This table lists the screennames of authorized users

// Using "exact" as an index method will help make searches more performant

datatable AuthorizedUsers

  load ScreenName {index="exact"} from

    mememe@hotmail.com

    uberbetatester@live.com

    popaandmoma@live.com

    mygloriousboss@live.com

function UserIsAuthorized()

  if ShellMode() // Shellmode() returns true if we're in the SDK

    return true

  SN = get ScreenName in AuthorizedUsers where ScreenName is SYS.User.ScreenName

    // Found the screename: access granted!

    return true

  return false

// Here the in-context is set to 1000 to make sure that any other routine is overruled.

context Unauthorized {out-of-context="0" in-context="1000" condition="!UserIsAuthorized()"}

start context Unauthorized

+ =AnythingStrong

  - Sorry, I'm in closed beta phase and can't talk to you yet. No peeping!

// Within a context, regular matching still happens as they're all subject to the same adjustment.

? But I am a Very Important Person!

  - The Boss said: no exceptions.

end context Unauthorized

  Another use, very similar in implementation, is to restrict certain debug or testing queries to a set of super-users, listed this time in a text file. The textfile-based table is easier to maintain independently from the code, and can be changed without having to restart the agent: all you need is to set an expire date for the file to be reloaded.

datatable SuperUsers {expire="in one day"}

  // The list will be timed out and reloaded once a day from the file.

  load ScreenName {index="exact"} from file

    superusers.txt

function IsSuperUser()

  if ShellMode()

    return true

  SN = get ScreenName in SuperUsers where ScreenName is SYS.User.ScreenName

    return true

  return false

context RestrictedStrings {out-of-context="0" in-context="100" condition="IsSuperUser()"}

start context RestrictedStrings

// This topic is only accessible to the right people:

+ debug all variables

  - As you wish.

  dbg_display STORED_USER_VARIABLES

That’s it for today. See you tomorrow for another round of goodies!