Openwave Imps Developer Guide

Openwave Instant Developer’s Guide
Messaging and Presence

Server
Release 2.0 (CR)
Openwave Systems Inc.

1400 Seaport Boulevard
Redwood City, CA 94063 U.S.A.
http://www.openwave.com
Part Number IMDG-20-002
Legal Notice
Copyright © 1999–2003 Openwave Systems Inc. All rights reserved.
The contents of this document constitute valuable proprietary and confidential property of Openwave Systems Inc. and are
provided subject to specific obligations of confidentiality set forth in one or more binding legal agreements. Any use of this
material is limited strictly to the uses specifically authorized in the applicable license agreement(s) pursuant to which such
material has been furnished. Any use or disclosure of all or any part of this material not specifically authorized in writing by
Openwave Systems Inc. is strictly prohibited.
Openwave and the Openwave logo are registered trademarks and/or trademarks of Openwave Systems Inc. in various
jurisdictions. All other trademarks are the properties of their respective owners.
For technical information on Openwave products, go to

http://support.openwave.com
Please send comments about this book or corrections to

doc-comments@openwave.com
2 Developer’s Guide CONFIDENTIAL AND PROPRIETARY 2.0 (CR)

Contents
About This Book 5
1 Wireless Village Standards Conformance 7

The Wireless Village Initiative 7
Overview of the Wireless Village Initiative 7
Wireless Village Architecture 8
Wireless Village Primitives 9
Openwave’s IMPS Implementation of Wireless Village 9
General Conformance 9
General Service Attributes 10
Service Access Point Requirements 11
Presence Service Element Requirements 12
Instant Messaging Service Element Requirements 12
Group Service Element Requirements 14
2 Wireless Village Extensions 15

Typing Indicator Primitives 15
Subscriber Typing 15
Updating Typing Status 16
Extensions to the Wireless Village DTD 18
WBXML Encoding Typing Indicator Token Assignments 18
XML Examples 19
SMS Encoding 20
SMS Examples 21
3 Implementing a Bot 23
Guidelines for Implementing Bots 23
Example Bots 24
RoShamBot 25
TriviaBot 25
BJStrategy Bot 26
TrafficBot 27
Bot Java Classes 29
2.0 (CR) CONFIDENTIAL AND PROPRIETARY Developer’s Guide 3

Contents

About This Book
This book provides information for developers tasked with developing applications
that will work with Openwave’s Instant Messaging and Presence Server (IMPS)
system. It provides two primary sets of information:
• Conformance statement indicating which Wireless Village primitives are
supported and information on extensions to the Wireless Village specification.
• APIs and guidelines for defining bots.
To use this book, you should have knowledge of the Wireless Village protocol and
experience with Java and writing Java scripts.
For more information about the IMPS product, refer to the other books in the
IMPS documentation set:
• For a list of known issues, new features, and the most up-to-date information
on the version of IMPS you are installing, see the Release Notes.
• For a general introduction to the IMPS system, its architecture and supported
features and functions, see the Overview.
• For information about planning, installing, and configuring IMPS installations,
see the Installation Guide.
• For administration, operations, provisioning, and maintenance information, see
the Working with the IMPS System.
• For conceptual information on agents, clients, and logging as well as
descriptions for each IMPS utility, configuration property, object, attribute,
and log event, see the Reference.

About This Book

1 Wireless Village Standards
Conformance
1
Openwave’s IMPS provides a full Service Access Point that conforms with the
Wireless Village Version 1.1 initiative. IMPS supports all mandatory requirements
of the initiative, as well as some conditional requirements that are applicable to
implementations supporting WAP and SMS client interfaces via HTTP, Wireless
Session Protocol (WSP) and SMS transport bindings. This chapter provides details
regarding the optional requirements that are supported.
Openwave’s IMPS Wireless Village implementation includes support for:
• Client Server Protocol (CSP)
Supports SMS and HTTP bindings for Wireless Village embedded clients.
• Applications Interface
Enables games, buddy bots, and content services to be deployed, which help
stimulate increased usage
The Wireless Village Initiative

The Wireless Village initiative for Mobile Instant Messaging and Presence Services
(IMPS), founded in April 2001 by Ericsson, Motorola, and Nokia, was established
to define and promote a set of universal specifications for IMPS. This release of
Openwave’s IMPS introduces the implementation of portions of this initiative.
For details on the Wireless Village initiative, see http://www.wireless-village.org.
Overview of the Wireless Village Initiative

The stated goal of the Wireless Village initiative is “to ensure interoperability of
mobile instant messaging and presence services while building community both
around the initiative and through the deployment of innovative new Instant
Messaging services.” The Wireless Village IMPS includes four primary features:
• Presence
• Instant Messaging
• Groups
• Shared Content

1 Wireless Village Standards Conformance
The Wireless Village Initiative
Presence includes client device availability, user status, location, client device
capabilities, and searchable personal statuses such as mood. Access control features
put the control of the user presence information in the users’ hands. Wireless
Village enhances the familiar concept of Instant Messaging by enabling
interoperative mobile IM. Wireless Village allows both operators and end-users to
create and manage groups. Users can invite their friends and family to chat in
group discussions. Operators can build common interest groups where end-users
can meet each other online. The final feature, Shared Content, allows users and
operators to set up their own storage area where they can post pictures, music, and
other multimedia content while enabling the sharing with other individuals and
groups in an IM or chat session.
These features, taken in part or as a whole, provide the basis for new services that
build upon a common interoperable framework—Wireless Village.
The Wireless Village specification defines how the IMPS system should interface
with existing wireless network infrastructures. It also provides an open interface to
existing IM communities on the Internet. To the greatest extent possible, the
protocol uses XML to represent the protocol data being exchanged during an IMPS
session. The architecture and open protocol supports multiple server deployments
such that the operator can host their own service, in addition to enabling the
enterprise with their own IMPS servers.
Wireless Village Architecture

The Wireless Village server is the central point in the system. It is composed of four
Application Service Elements that are accessible via the Service Access Point. The
Application Service Elements are:
• Presence Service Element
• Instant Messaging Service Element
• Group Service Element
• Content Service Element
The Wireless Village client architecture supports two distinct client types: (1) an
embedded client and (2) a Command-Line Interface (CLI) client. Each client
communicates with the Wireless Village server/system to accomplish IMPS features
and functions and to provide users with IMPS services.
Interoperability between Wireless Village servers and clients, and between Wireless
Village servers is achieved through the Wireless Village protocol suite. The protocol
suite consists of the Client-Server Protocol (CSP), Server-Server Protocol (SSP),
and Command Line Protocol (CLP). The protocol suite runs at the application
level and is compliant with IETF RFC 2778, RFC 2779 and the IMPP CPIM
model. The Wireless Village protocol suite may run independently over different
transport layer and bearer protocols.

Wireless Village Standards Conformance
Wireless Village Primitives
The Wireless Village CSP is composed of primitives, each of which represents a
single function. In other words, a primitive represents a single request from the
client to the server or from the server to the client. For example, a client can send a
login request to the server and the server can send a login response to the client.
Wireless Village uses XML to represent the primitives and allows various bindings
for transporting and encoding the data. The allowed transports are HTTP and
SMS. The allowed encodings for HTTP are XML or WBXML (compressed XML).
Wireless Village has created its own text-based encoding format for SMS.
Because the HTTP binding is asymmetric (in other words, the client can initiate a
conversation with the server but the server cannot initiate a conversation with the
client), the server must rely on push channels to initiate communication with the
client. The Wireless Village HTTP binding supports three push channels (TCP,
UDP, and WAP Push).
Openwave’s IMPS Implementation of Wireless Village

This release of Openwave’s IMPS supports a subset of the Wireless Village
Presence, Instant Messaging, and Groups primitives and supports the Wireless
Village Client-Server Protocol (CSP). The supported primitives are listed in the
following sections. In addition, Openwave IMPS has extended the Wireless Village
protocol to accommodate various features of Openwave’s IMPS application. See
Chapter 2 for a list of extensions.
The IMPS system supports any Wireless Village client, restricted to the set of
features indicated in this chapter. The Openwave implementation supports only
one push channel: TCP (WAP Push and UDP are not supported). The Openwave
IMPS servers use TCP for pushing to 3G network wireless clients. When
communicating with non-3G wireless clients, the client determines the type of
push that is used.
General Conformance
Openwave’s IMPS system conforms to the Wireless Village initiative as follows:
• Service Requirements IMPS supports Service Access Point, Instant Messaging,
Presence, and Group Service Element functions. IMPS does not support
Content Service Element functions.
• XML Encoding Requirements IMPS supports both HTTP transport bindings
and conforms to all XML encoding requirements
• Address Requirements IMPS does not support client addressing. Local and
external user addressing are supported.
• Session Requirements IMPS supports all session requirements.
• Transaction Requirements IMPS supports all transaction requirements.

• Transport Binding Requirements IMPS provides support for standalone

TCP/IP binding in the Communications Initiation Request (CIR) or push
channel. No other CIR channel protocol binding is supported. In the data
channel, IMPS supports HTTP and SMS binding, and also supports Wireless
Session Protocol (WSP) binding, provided that the appropriate WAP gateway
is in place. IMPS does not support HTTP/S binding in the data channel.
• SMS Binding Requirements IMPS supports all requirements for SMS binding.
General Service Attributes

Table 1-1 indicates IMPS support provided for the General Service Attributes.
Table 1-1. General Service Attributes
Requirement Supported?
Service requirements
Service Access Point Y

Instant Messaging Service Element Y
Presence Service Element Y
Group Service Element Y
Content Service Element N
XML Encoding, Addressing, Session, and Transaction requirements
XML Encoding (all) Y

Local user addressing Y
External user addressing Y
Client addressing N
Session requirements (all) Y
Transaction requirements (all) Y
Transport Binding and SMS Binding requirements
Transport binding for data channel Y

Transport binding for CIR channel N (TCP/IP only)
HTTP binding in data channel Y
HTTP/S binding in data channel N
WSP 1.2 binding in data channel Y
WSP 2.0 binding in data channel Y
SMS binding in data channel Y
WAP push SMS binding in CIR channel N
WAP push UDP/IP binding in CIR channel N
Standalone UDP/IP binding in CIR channel N
Standalone TCP/IP binding in CIR channel. N

Table 1-1. General Service Attributes
Requirement Supported?
With WSP 1.2 or WSP 2.0 bindings for data N/A

channel, only WAP SMS binding or WAP UDP
binding is used in CIR channel.
SMS binding in data channel (all) Y
Service Access Point Requirements

IMPS provides support for all Wireless Village 1.1 Service Access Point
requirements except the following:
• The Communication Initiation Request primitive is not supported for any
protocol other than TCP/IP.
• IMPS does not return the supported sub protocol version when responding to
a CapabilityRequest primitive from the client.
• Since the only supported binding for Client Initiation Requests is TCP/IP,
IMPS only returns the IP address and port in the response to client requests for
that protocol binding, and not for CIR over UDP or WAP SMS.
Table 1-2 indicates IMPS support provided for the Service Access Point functions.
Table 1-2. Service Access Point functions
Function Supported?
Status primitive Y
Communication Initiation Request primitive N (TCP/IP only)
2-way login Y
4-way login Y
Logout originating from client Y
Server originated disconnect Y
Keep-Alive transaction (all) Y
Get Service Provider Info Y
Service negotiation Y
Client Capability negotiation Y
Search based on user properties (all) Y
Search based on group properties (all) Y
Stop search Y
Invitation (all) Y
Cancel invitation (all) Y

Presence Service Element Requirements

The Presence Service element is supported in its entirety for all mandatory
requirements. Among the optional functional requirements, IMPS supports all
except the following:
• Create, delete, and get attribute list transactions are not supported, nor are any
of the conditional requirements which depend on them.
• Get watcher list transactions and their conditional requirements are not
supported.
Table 1-3 indicates IMPS support provided for the Presence Service Element
functions.
Table 1-3. Presence Service Element functions
Function Supported?
Get list of contact lists (IDs) (all) Y

Create contact list (all) Y
Delete contact list (all) Y
Manage contact list (all) Y
Create attribute list N
Delete attribute list N
Get attribute list N
Subscribe presence (all) Y
Unsubscribe presence (all) Y
Get watcher list N
Presence notification (all) Y
Get presence (all) Y
Update presence (all) Y
Reactive presence authorization request (all) Y
Reactive presence authorization of user Y
Cancel presence authorization (all) Y
Instant Messaging Service Element Requirements

IMPS supports all mandatory functional requirements for the Instant Messaging
Service Elements. Additionally, the Openwave IMPS service access point supports
the functional requirements that are conditional upon support for the HTTP or
WAP transport protocol, such as setting delivery method.

Among the optional functional requirements for Instant Messaging, IMPS supports
all except the following:
• Get list of message transaction is not supported, nor are the conditional
requirements that depend on it.
• Reject message transaction is not supported, nor its conditional requirements.
Additionally, certain optional conditional requirements are not supported, even if
the function itself is supported. These include:
• The Openwave IMPS does not switch delivery methods to Notify/Get for
MMS messages.
• When using the NewMessage primitive, IMPS does not identify the sending client
by Client-ID.
• The MessageInfo structure of a GetMessageRequest/Response refers to a message
only by MessageID, not by MessageURI.
Table 1-4 indicates IMPS support provided for the Instant Messaging Service
Element functions.
Table 1-4. Instant Messaging Service Element functions
Function Supported?
Setting delivery method Y
Send message (all) Y
Push message (all) Y
Pull message Y
Either pushing or pulling messages Y
Get list of messages Y
Reject message N
New message Y
Message notification Y
Get message Y
Delivery status report (all) Y
Forward message (all) Y
Get list of blocked entities (all) Y
Block entity (all) Y

Group Service Element Requirements

IMPS supports the two mandatory functional requirements for Group Service
Elements: Join Group and Leave Group Transactions. No other functional
requirements in this category are supported. Table 1-5 indicates IMPS support for
the Group Service Element functions
Table 1-5. Group Service Element functions
Function Supported?
Group creation (all) Y
Group deletion (all) Y
Get group properties (all) Y
Set group properties (all) Y
Get group members (all) Y
Add group members (all) Y
Remove group members (all) Y
Member access rights (all) Y
Subscribe group notice (all) Y
Group change notification (all) Y
Join group (all) Y
Leave group (all) Y
Reject user(s) from group (all) Y

2 Wireless Village Extensions 2
This chapter provides information on the extensions made to the Wireless Village
standard that are implemented in Openwave’s IMPS. There are two types of
extensions made:
• Typing Indicator Primitives
• Extensions to the Wireless Village DTD
Typing Indicator Primitives

Two typing indicator primitives are supported: subscriber typing and updating
typing status.
Subscriber Typing
A user may get/set/unset typing change subscription status. The client sends the
SubscribeTypingRequest message to the server. The message contains the type of the
requested operation. The answer from the server for the operation is the
SubscribeTypingResponse message or Status if an error occurs. While the
subscription is active, the user will receive TypingUserRequest messages. See
Figure 2-1.
Figure 2-1. Subscriber typing status client-server communication
Client 1 Server
SubscribeTypingRequest
SubscribeTypingResponse
Primitive Direction
SubscribeTypingRequest Client —> Server

SubscribeTypingResponse Client <— Server

2 Wireless Village Extensions
Typing Indicator Primitives
Subscriber Typing Request

Information elements used to support the SubscribeTypingRequest extension are (an
‘M’ indicates it is a mandatory element):
Information element Required Type Description
MessageType M SubscribeTypingRequest Message identifier

Transaction-ID M String Transaction request
identifier
Session-ID M String Session identifier
Subscription-State M Enumerated character G for Get,
S for Set,
U for Unset
Subscriber Typing Response

Information elements used to support the SubscribeTypingResponse extension are
(an ‘M’ indicates it is a mandatory element):
MessageType M SubscribeTypingResponse Message identifier

Transaction-ID M String Transaction request
identifier
Subscription-State M Boolean Subscription status
indicator
Updating Typing Status

A user may update their typing status by sending a TypingRequest to the server
containing and IsTyping element. If the update represents a change in the user’s
typing status, all users that have enabled typing indicators and have recently been
messaging with the user will receive a TypingUserRequest. The TypingUserRequest
will contain information identifying the user who is typing and the current state of
the user’s typing status. See Figure 2-2.

Wireless Village Extensions
Typing Indicator Primitives 2
Figure 2-2. Updating typing status client-server communication
Client 1 Server Client 2
TypingRequest
Status TypingUserRequest
Status
Primitive Direction
TypingRequest Client —> Server

TypingUserRequest Client <— Server
Typing Request
Information elements used to support the TypingRequest extension are (an ‘M’
indicates it is a mandatory element):
MessageType M TypingRequest Message identifier

Transaction-ID M String Transaction request identifier
Recipients M Structure Identifies the user(s) to notify
about typing (user ID, contact list
ID, screen name)
IsTyping M Boolean T indicates user is typing
F indicates user has stopped typing
Typing User Request

Information elements used to support the TypingUserRequest extension are (an ‘M’
indicates it is a mandatory element):
MessageType M TypingUserRequest Message identifier

Transaction-ID M String Transaction request identifier

Extensions to the Wireless Village DTD
Sender M Structure User or screen name whose

typing state is being sent
IsTyping M Boolean T indicates user is typing
F indicates user has stopped
typing

The following five extensions are made to the Wireless Village DTD:
<!ELEMENT Typing-Request (Recipient, IsTyping)>
<!ELEMENT TypingUser-Request (Sender, IsTyping)>
<!ELEMENT IsTyping (#PCDATA)>
<!ELEMENT SubscribeTyping-Request (SubscribeType)>
<!ELEMENT SubscribeTyping-Response (Value)>
WBXML Encoding Typing Indicator Token Assignments

WBXML token assignments for typing indicators are listed below. All values are in
decimal.
Code Typing indicator
55 Typing-Request
56 TypingUser-Request
57 SubscribeTyping-Request
58 IsTyping
59 SubscribeTyping-Response

XML Examples
Typing-Request:
<WV-CSP-Message xmlns="http://www.wireless-village.org/CSP1.1">
<Session>
<SessionDescriptor>
<SessionType>Inband</SessionType>
<SessionID>SESSIONID</SessionID>
</SessionDescriptor>
<Transaction>
<TransactionDescriptor>
<TransactionMode>Request</TransactionMode>
<TransactionID>TRANSACTIONID</TransactionID>
</TransactionDescriptor>
<TransactionContent xmlns="http://www.wireless
-village.org/TRC1.1">
<Typing-Request>
<Recipient>
<User><UserID>wv:recipient@software.com</UserID></User>
</Recipient>
<IsTyping>T</IsTyping>
</Typing-Request>
</TransactionContent>
</Transaction>
</Session>
</WV-CSP-Message>
TypingUser-Request:
<Session>
<SessionDescriptor>
<Transaction>
<TransactionContent xmlns="http://www.wireless
-village.org/TRC1.1">
<TypingUser-Request>
<Sender>
<User><UserID>wv:sender@software.com</UserID></User>
</Sender>
<IsTyping>T</IsTyping>
</TypingUser-Request>
</Transaction>
</Session>
</WV-CSP-Message>

SubscribeTyping-Request (get):
<Session>
<SessionDescriptor>
<Transaction>
<TransactionContent xmlns="http://www.wireless-village.org/TRC1.1">
<SubscribeTyping-Request>
<SubscribeType>G</SubscribeType>
</SubscribeTyping-Request>
</Transaction>
</Session>
</WV-CSP-Message>
SubscribeTyping-Response (to get):

<Session>
<SessionDescriptor>
<Transaction>
<TransactionMode>Response</TransactionMode>
<TransactionContent xmlns="http://www.wireless-village.org/TRC1.1">
<SubscribeTyping-Response>
<Value>T</Value>
</SubscribeTyping-Response>
</Transaction>
</Session>
</WV-CSP-Message>
SMS Encoding
Information elements used to support the DTD extensions are:
Element Code
TypingRequest TR
TypingUserRequest TU
SubscribeTypingRequest SY

SubscribeTypingResponse YS
IsTyping IY
SMS Examples
TypingRequest:
WV11TR761 SI=SESSIONID UI=wv:recipient@software.com IY=T
TypingUserRequest:
WV11TU761 SI=SESSIONID UI=wv:sender@software.com IY=T
SubscribeTypingRequest (get):
WV11SY761 SI=SESSIONID SU=G
SubscribeTypingResponse:
WV11YS761 SI=SESSIONID SS=T


3 Implementing a Bot 3
Bot, short for robot, is an artificial IMPS user containing logic that dictates
responses to a chat invitation. Bots are defined using Java and including one or
more java classes provided by the IMPS system.
This chapter defines the basic information for implementing a bot, describes the
example bots provided with the current release, and defines the three base java
classes implemented to support the definition of bots.
IMPORTANT The example bots are provided for illustrative purposes only. They
are not expected to be used in a production deployment. No quality assurance
testing on these bots has been performed. Copyright issues may apply in the
case of the TriviaBot.
Guidelines for Implementing Bots

To implement a bot in the IMPS system, you must do the following:
1 Define the bot using java. The bot must include at a minimum the
chatResponder class. Other classes should be extended as needed depending on
the bot function.
2 Create or register a user whose name will be associated with a specific bot. This
can be accomplished using the web access wizard.
Bots are associated with a user name, similar to other end users of the IMPS
service. End users access a bot by adding the bot as a buddy, specifying the bot
user name, and then starting a chat with the bot.
3 Set up the bot user to auto-accept buddies.
Bots must be set up to auto accept players who add them as buddies.
Alternatively, if the system default is set to auto accept:
persona.privacy.default=accept
Then, all users are automatically defined to auto accept. This property is
defined in the common.cfg file for the Agent Server.

3 Implementing a Bot
Example Bots
4 Launch or initialize the bot.

This is typically performed via a cron job or start up script which contains the
bot initialization commands. The initialization command should contain a
parameter that indicates the bot user name.
By convention and the examples provided in this chapter, when launching a
bot, the ChatResponder requires specification of an agent descriptor. For the
example bots, the form used is:
/cloudname/persona/username
For example:
/imps.telco.com/persona/trivia@telco.com
Example Bots
Four example bots are provided for illustrative purposes. Bots are able to maintain
the state of the chat and the number of users interacting with it.
IMPORTANT The example bots provided are not launched by default. You must
create your own script or initialize them for the system you are running. Refer
to the usage statement at the bottom of bot example for the initialization
command syntax.
All the example bots provided are initiated by initiating a chat session with the bot.
The convention used is for the user to enter:
?
to activate each of these example bots.
You can view the java code for each of these bots by accessing the following
directory on the Application Server:
$IM_HOME/appserver/apps/bots
The three Java base classes or files called by these bots can be obtained here:
$IM_HOME/appserver/src.zip
Unzip this file. The contents include:
ChatResponder.java
ChatState.java
ChatUser.java
./examples/BJStrategy.java
./examples/RoShamBot.java
./examples/TrafficBot.java
./examples/TrafficParser.java
./examples/TriviaBot.java
Additional files called by these bots can be obtained here:
$IM_HOME/appserver/apps/bots/lib

Implementing a Bot
Example Bots 3
RoShamBot
The RoShamBot example implements the game “rock-paper-scissors.” This bot
provides an example of a game that:
• Initiates the game by prompting the user to enter one of three valid replies:
r - rock, s - scissors, or p - paper.
• Uses a random generator to determine its own entry.
• Compares the two entries—the user’s and its own—to determine who won.
• Replies with the game result and the running score of wins, losses, and ties.
The RoShamBot continues to play the game until the player quits the chat.
A sample listing (from a PC client) showing the interaction between a player and
the RoSham bot is shown below:
?
roshambot: 2:32 PM
type: r for rock, s scissors or p for paper {r | s | p}
Player: 2:32 PM
r
roshambot: 2:32 PM
you: rock, me: rock, RESULT: tie (0 - 0 - 1)
Player: 2:32 PM
s
roshambot: 2:32 PM
you: scissors, me: rock, RESULT: lose (0 - 1 - 1)
Player: 2:32 PM
p
roshambot: 2:32 PM
you: paper, me: scissors, RESULT: lose (0 - 2 - 1)
Player: 2:32 PM
r
roshambot: 2:32 PM
you: rock, me: paper, RESULT: lose (0 - 3 - 1)
Player: 2:32 PM
r
roshambot: 2:32 PM
you: rock, me: rock, RESULT: tie (0 - 3 - 2)
Player: 2:32 PM
r
roshambot: 2:32 PM
you: rock, me: scissors, RESULT: win (1 - 3 - 2)
TriviaBot
The TriviaBot example implements a game of trivia. This bot:
• Initiates a game by prompting the user to select from one to nine categories of
questions:
Choose set of questions: { #1 | #2 | #3 | #4 | #5 | #6 | #7 | #8 | #9 }
• Loads in a text file (trivia.txt) that contains both questions and answers
• Compares the user response with the correct answer

Example Bots
• Replies with the game result, indicating if the user was correct or incorrect, and
the running score
The TriviaBot continues to play the game for a series of ten questions in the
category chosen. To continue play, the player must enter a ? to start a new game.
the trivia bot is shown below:
Player: 4/1/2003 at 5:46 PM
?
trivia: 4/1/2003 at 5:46 PM
Choose set of questions: { #1 | #2 | #3 | #4 | #5 | #6 | #7 | #8 | #9 }
Player: 4/1/2003 at 5:46 PM
#2
trivia: 4/1/2003 at 5:46 PM
Q: How tall is the Statue of Liberty from her heel to the top of her head
(in feet)? { 111 | 183 | 251 | 384 }
Player: 4/1/2003 at 5:46 PM
384
trivia: 4/1/2003 at 5:46 PM
The answer was 111. 0 out of 1
trivia: 4/1/2003 at 5:46 PM
Q: In what year did the American Civil War end? { 1776 | 1812 | 1865 |
1914 }
Player: 4/1/2003 at 5:46 PM
1865
trivia: 4/1/2003 at 5:46 PM
RIGHT! Player got 1865. 1 out of 2
trivia: 4/1/2003 at 5:47 PM

Q: What constitutional amendment is the right to bear arms? { 1st | 2nd |
18th | 22nd }
Player: 4/1/2003 at 5:48 PM
2nd
trivia: 4/1/2003 at 5:48 PM
RIGHT! Player got 2nd. 5 out of 10
trivia: 4/1/2003 at 5:48 PM
Game over. You got 5 out of 10
BJStrategy Bot
The BJStrategy bot implements a game that teaches the strategy behind the black
jack card game. This bot:
• Initiates a game by prompting the user on the four choices available to them:
type: s for stand, p split, d for double, or h for hit
• It then “deals” a black jack hand, for example:
dealer: 3
player: pair of 4's
move: {s | p | d | h}
• It uses a random generator to determine the deal.

Implementing a Bot
Example Bots 3
• It incorporates the logic of the black jack card game, game rules derived from a
chart.
• Compares the user response with the correct black jack card game strategy
response
• Replies with the game result, indicating if the user was correct or incorrect, and
the running score
The BJStrategy continues to play the game until the player enters “quit” or “reset.”
the BJStrategy bot is shown below:
dealer: 3
player: pair of 4's
move: {s | p | d | h}
Player: 12:27 PM
p
bjstrategy: 12:28 PM
wrong! you should have hit (0 / 1 - 0%)
dealer: 2
player: pair of 6's
move: {s | p | d | h}
Player: 12:27 PM
p
wrong! you should have hit (0 / 2 - 0%)
dealer: 9
player: pair of 9's
move: {s | p | d | h}
Player: 12:27 PM
p
correct (1 / 3 - 33%)
dealer: 3
player: soft 15
move: {s | p | d | h}
TrafficBot
The TrafficBot implements an information bot that can be queried for the speed or
incident report on a particular highway. It also updates the status periodically. One
of two highways are used in this example: I90 and HW 405 in the Puget Sound area
of Washington state. This bot:
• Is initiated by opening a chat and querying with a “?.”
• Prompts the user to enter:
Type 'a' to see speed at all stations
Type 'm' to see incident report

Example Bots
• Responds with information derived from the following URL:

http://www.wsdot.wa.gov/PugetSoundTraffic/
• Information can be accessed for each of two directions, east and west, for each
highway. Therefore, four user names/persona agents must be defined, one for
each freeway/direction:
520W
520E
90W
90E
The command syntax to initiate the bot is:
TrafficBot [<agentname>=<freeway number>-<direction>]")
For example:
TrafficBot 520w=520-W get_traffic=405-N"
A sample listing (from a PC client) showing the interaction between a user and the
TrafficBot is shown below:
90W: 2:27 PM
Type 'a' to see speed at all stations
Type 'm' to see incident report
User: 2:27 PM
a
90W: 2:27 PM
90W station speeds
68 - 23rd Ave S
63 - 35th Ave S
96 - West Highrise WB
71 - Midspan WB
80 - East Highrise WB
70 - Isl Crest Way-EB
62 - Shorewood Dr
64 - E Mercer Way-EB
50 - E Channel Bridge
45 - 118th Ave SE
58 - 118th Ave SE
50 - Richards Rd
50 - 136th Ave SE
61 - 136th Ave SE
60 - 136th Ave SE
68 - 161st Ave SE
60 - 164th Ave SE
55 - 169th Ave SE
59 - 182nd Ave SE
56 - 188th Ave SE
66 - 200th Ave SE
62 - 12th Ave NW

Implementing a Bot
ChatState 3
User: 2:27 PM
m
90W: 2:27 PM
Tuesday May 07, 2002 + 16:56:15
Operator ID : PASKOK
Heading : BULLETIN
Message : FOR COMMUTER INFO CALL 206 DOT-HIWY ( 368-4499 )
FOR CURRENT CONSTRUCTION INFORMATION PLEASE VISIT

http://www.wsdot.wa.gov/pugetsoundtraffic/constr.htm
Wednesday Apr 02, 2003 + 13:04:47
Operator ID : PASKOK
Heading : INCIDENT
Message : INCIDENT INFORMATION ( * = New Incident / Update )
CURRENT OPERATOR: Pasko
NO BLOCKING INCIDENTS TO REPORT
Bot Java Classes

There are three Java base classes implemented to support the definition of bots.
They are:
• ChatResponder
• ChatState
• ChatUser
ChatResponder
Represents the bot and contains the logic for how the bot responds to an invitation
to chat.
Discussion The chatResponder class extends the Contract class. It is the only required element
used to define a bot. It represents a connection to a persona and handles all the
message between users and the bot.
When launching a bot, the ChatResponder requires specification of an agent
descriptor. For all bots, this is in the form:
/cloudname/persona/username
For example:
/imps.telco.com/persona/trivia@telco.com
ChatState
Maintains the chat session for a bot.
Discussion The chatState class is optional. It is used when the bot requires maintaining state
information for multiple users, such as when a bot maintains a game score.

ChatUser
ChatUser
Maintains information on a user in a particular chat. A user may have one of these
pr chat.
Discussion Bots can chat with a number of users. The chatUser class tracks the user
information, such as their display name, if they are connected, and so on.

Openwave Imps Developer Guide

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Openwave Imps Developer Guide

Transféré par

Droits d'auteur :

Formats disponibles

Openwave Instant Developer’s Guide

Messaging and Presence

Openwave Systems Inc.

For technical information on Openwave products, go to

Please send comments about this book or corrections to

2 Developer’s Guide CONFIDENTIAL AND PROPRIETARY 2.0 (CR)

About This Book 5

1 Wireless Village Standards Conformance 7

2 Wireless Village Extensions 15

2.0 (CR) CONFIDENTIAL AND PROPRIETARY Developer’s Guide 3

4 Developer’s Guide CONFIDENTIAL AND PROPRIETARY 2.0 (CR)

2.0 (CR) CONFIDENTIAL AND PROPRIETARY Developer’s Guide 5

6 Developer’s Guide CONFIDENTIAL AND PROPRIETARY 2.0 (CR)

The Wireless Village Initiative

Overview of the Wireless Village Initiative

2.0 (CR) CONFIDENTIAL AND PROPRIETARY Developer’s Guide 7

Wireless Village Architecture

8 Developer’s Guide CONFIDENTIAL AND PROPRIETARY 2.0 (CR)

Openwave’s IMPS Implementation of Wireless Village

2.0 (CR) CONFIDENTIAL AND PROPRIETARY Developer’s Guide 9

• Transport Binding Requirements IMPS provides support for standalone

General Service Attributes

Table 1-1. General Service Attributes

Service Access Point Y

XML Encoding (all) Y

Transport binding for data channel Y

10 Developer’s Guide CONFIDENTIAL AND PROPRIETARY 2.0 (CR)

With WSP 1.2 or WSP 2.0 bindings for data N/A

Service Access Point Requirements

Table 1-2. Service Access Point functions

2.0 (CR) CONFIDENTIAL AND PROPRIETARY Developer’s Guide 11

Presence Service Element Requirements

Table 1-3. Presence Service Element functions

Get list of contact lists (IDs) (all) Y

Instant Messaging Service Element Requirements

12 Developer’s Guide CONFIDENTIAL AND PROPRIETARY 2.0 (CR)

Table 1-4. Instant Messaging Service Element functions

2.0 (CR) CONFIDENTIAL AND PROPRIETARY Developer’s Guide 13

Group Service Element Requirements

Table 1-5. Group Service Element functions

14 Developer’s Guide CONFIDENTIAL AND PROPRIETARY 2.0 (CR)

Typing Indicator Primitives

SubscribeTypingRequest Client —> Server

2.0 (CR) CONFIDENTIAL AND PROPRIETARY Developer’s Guide 15

Subscriber Typing Request

Information element Required Type Description

MessageType M SubscribeTypingRequest Message identifier

Subscriber Typing Response

Information element Required Type Description

MessageType M SubscribeTypingResponse Message identifier

Updating Typing Status

16 Developer’s Guide CONFIDENTIAL AND PROPRIETARY 2.0 (CR)

Client 1 Server Client 2

TypingRequest Client —> Server

Information element Required Type Description

MessageType M TypingRequest Message identifier

Typing User Request

Information element Required Type Description

MessageType M TypingUserRequest Message identifier

2.0 (CR) CONFIDENTIAL AND PROPRIETARY Developer’s Guide 17

Sender M Structure User or screen name whose

Extensions to the Wireless Village DTD

WBXML Encoding Typing Indicator Token Assignments