<?php

//t-gram's model (short-sighted IMHO):
$keyboard = array(
   //row_0
    array(
      'my_command_0_0',
      'my_command_0_1,
    ),
    array(
      'my_command_1_0'
      'my_command_1_1',
      'my_command_1_2',
    ),
);

//my idea
$my_keyboard = array(
   //row_0
    array(
      array(
        'display_command' => 'my_display_to_user_command_0_0',
        'actual_command'  => 'my_actual_command_0_0',
      ),
      array(
        'display_command' => 'my_display_to_user_command_0_1',
        'actual_command'  => 'my_actual_command_0_1',
      ),
    ),
    //row 1
    array(
      array(
        'display_command' => 'my_display_to_user_command_1_0',
        'actual_command'  => 'my_actual_command_1_0',
      ),
      array(
        'display_command' => 'my_display_to_user_command_1_1',
        'actual_command'  => 'my_actual_command_1_1',
      ),
      array(
        'display_command' => 'my_display_to_user_command_1_2',
        'actual_command'  => 'my_actual_command_1_2',
      ),
    )
);

/**
 * advatages of the second approach:
 * the 'command' that's being displayed is just that (a property of the display, which need not be perfectly mapped to the backend command)
 *
 * example: a user issues a command to get a music track: 'top10 dance'.  If that user wants to get
 * another music track, a natural command would be 'next'.  Instead of forcing the server to
 * maintain additional state, this type of problem is easily solved by the paradigm above:
 *
 * 'display_command' is what is displayed to the user.
 *
 * if that command is clicked, the 'actual_command' gets send back to the server.
 *
 * While the client would have to deal with this logic, it's preferable
 * for the client to bear this minor burden than for a server to have to maintain this state per-user.
 * Upon opening up this API to the public, I think that developers will very much like this feature.
 */