TableMan Service

TableMan provides a variety of functions and notifications for table management. Table status updates from T900’s are given to clients through the TableMan service.

Table Status Update

Table status updates can come from a variety of sources, including hand held T900’s. The LRSN server notifies clients of these updates using <TableUpdate> messages. Upon receiving any <TableUpdate> message, the client should acknowledge the message with a <TableUpdateAck> message. In the <TableUpdateAck> message, the client can indicate if the table update operation is valid and accepted, or was invalid and not accepted.

The LRSN may send <TableUpdate> messages to the client. Any <TableUpdate> message sent by the client to the LRSN server will be silently ignored.

If multiple clients are connected to the TableMan service, each client should send a <TableUpdateAck> message to the LRSN server. However, for purposes of accepting or denying the message, only the first <TableUpdateAck> which the server receives is used.

<TableUpdate> messages inform the client of table state changes from devices such as the T900.

Attribute	Description	Details
action	Indicates the state the table is being changed to. Possible values for this attribute are: `open` - Table is open (available for seating a party) `hold` - Table is being held for a party `bus` - Table is currently being bussed `seat` - Table is seated `close` - Table is closed (not open and not seated) `xfer` - Party seated at table is being moved to another table	Always present
table	Table action is being taken on. For transfer actions, this indicates the table the party is transferring to.	Always present
id	Transaction ID for `<TableUpdate>`. This value is used in the `<TableUpdateAck>` response. The value of the id attribute is an integer.	Always present
src	Location unique identifier of the device which initiated this `<TableUpdate>`. The value of this attribute is an alphanumeric. The exact form and meaning of this value are dependent upon the device involved and its configuration. The same device will always use the same src ID, though.	Always present
old_table	Indicates the table the party is transferring from.	Present if action is "xfer" For transfer actions

<!-- Example of bussing table 24 -->

<TableUpdate action="bus" table="24" id="4098" src="325:3" />

<!-- Example of a transfer from table 3 to table 4 -->

<TableUpdate action="xfer" table="4" old_table="3" id="5016" src="325:3" />

<!-- Example of closing table 17-->

<TableUpdate action="close" table="17" id="5018" src="00:09:5B:22:4E:B2" />

A <TableUpdateAck> is sent by a client sent in response to a <TableUpdate> message.

Attribute	Description	Details
id	Transaction ID (`id` attribute) from `<TableUpdate>` message.	Always present
ret	The `ret` attribute allows the client to indicate the validity of a table update. The possible `ret` values are: `ESUCCESS` - Operation successful `EINVAL` - Invalid `table` or `old_table` value * `EOPFAIL` - Transfer is not valid, for example, the transfer to table is not open. If `ret` is omitted, the result is assumed to be `ESUCCESS`.	Optional

Wait Time Check

A person using a T900 or other device may request the wait time for a particular type of table, for instance a non-smoking table for 4. This request is forwarded to connected clients through a <WaitCheck> message. The clients should respond with a <WaitStatus> message. This wait time information in this message is forwarded onto the original requesting device.

If more than one client responds with a <WaitStatus> message, the first message received by the LRSN server is the one used to relay message.

If a device such as a T900 requests a wait time, and the LRSN has a sufficiently recent wait time estimate, it will send the device the cached wait time instead of requesting a new wait time. This will reduce the user delay on the device.

Alternatively, the client may take advantage of the wait time cache and send unsolicited <WaitStatus> messages to the LRSN server. The server will cache the wait times in these messages, using them to answer hand held device requests. Doing this should always keep the user delay on the hand held to a minimum.

A <WaitCheck> message is sent to the client when a request has been made about wait times.

Attribute	Description	Details
id	The `id` attribute is included in the corresponding `<WaitStatus>` message.	Always present
size	The size attribute specifies what size tables wait times are being requested for. The value may either be a single number, or a semi-colon delimited list of numbers.	Always present
type	The `type` attribute indicates what type of table the wait time is being checked for. Values that may appear in this field are `Smoking` and `Non-smoking`.	Always present

<WaitCheck id="74" size"2;4;6;8" type="Non-smoking" />

A <WaitStatus> message is sent by the client to inform the LRSN server of the current wait times. The client should send a <WaitStatus> message when the it receives a <WaitCheck>. Alternatively, a client may send unsolicited <WaitStatus> messages to the LRSN server.

If the <WaitStatus> message is in response to a <WaitCheck> message, it should be for the same type of table that the <WaitCheck> specified. Further, all of the table sizes included in the <WaitCheck> message should be included in the <WaitStatus>, provided they are valid table sizes. Any invalid table sizes should be silently discarded from the table size list.

Attribute	Description	Details
size	The `size` attribute is a semi-colon delimited list of the table sizes this message contains wait times for.	Always present
time	The `time` attribute is a semi-colon delimited list of wait times. The `time` list is parallel to the size list. The wait times are in minutes.	Always present
type	The `type` attribute specifies wait type of tables this message has wait times for. As with the `<WaitCheck>` message, the type may be either `Smoking` or `Non-smoking`.	Always present
id	The value of the `id` attribute comes from the `<WaitCheck>` message this is responding to. The `id` attribute is not present for unsolicited `<WaitStatus>`.	Present if a response to a `<WaitCheck>` message
ttl	The `ttl` attribute defines the number of seconds the LRSN should continue to use the wait time estimates for this message. If it is not present, then the LRSN will use its default lifetime value. Once the `ttl` period has been exceeded, the LRSN will not use the values in this message.	Optional

The following example is an unsolicited <WaitStatus> message, and shows a 15 minute wait for a 2-top table, 20 minutes for a 4-top, and 35 minute for a 6-top, all non-smoking:

<WaitStatus size="2;4;6" time="15;20;35" type="Non-smoking" ttl=60 />