TableMan Service
Version 1.0
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>
<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:
| 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 | Always present |
src | Location unique identifier of the device which initiated this | Always present |
old_table | Indicates the table the party | 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" /><TableUpdateAck>
A <TableUpdateAck> is sent by a client sent in response to a <TableUpdate> message.
Attribute | Description | Details |
|---|---|---|
id | Transaction ID ( | Always present |
ret | The
If | 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 <WaitStatus> 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.
<WaitCheck>
A <WaitCheck> message is sent to the client when a request has been made about wait times.
Attribute | Description | Details |
|---|---|---|
id | The | 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 | Always present |
<WaitCheck id="74" size="2;4;6;8" type="Non-smoking" /><WaitStatus>
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 | Always present |
time | The | Always present |
type | The | Always present |
id | The value of the | Present if a response to a |
ttl | The | 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" />Updated 7 days ago
