Openwave Imps Developer Guide

8/8/2019 Openwave Imps Developer Guide

1/30

Openwave Instant

Messaging and Presence

Server

Release 2.0 (CR)

Developers Guide

Openwave Systems Inc.

1400 Seaport Boulevard

Redwood City, CA 94063 U.S.A.

http://www.openwave.com

Part Number IMDG-20-002
http://www.openwave.com/http://www.openwave.com/


2/30

2 Developers Guide CONFIDENTIAL AND PROPRIETARY 2.0 (CR)

Legal Notice

Copyright 19992003 Openwave Systems Inc. All rights reserved.

The contents of this document constitute valuable proprietary and confidential property of Openwave Systems Inc. and areprovided subject to specific obligations of confidentiality set forth in one or more binding legal agreements. Any use of thismaterial 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 byOpenwave Systems Inc. is strictly prohibited.

Openwave and the Openwave logo are registered trademarks and/or trademarks of Openwave Systems Inc. in variousjurisdictions. 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

[email protected]
http://support.openwave.com/mailto:[email protected]:[email protected]://support.openwave.com/


3/30

2.0 (CR) CONFIDENTIAL AND PROPRIETARY Developers Guide 3

Contents

About This Book 5

1 Wireless Village Standards Conformance 7

The Wireless Village Initiative 7Overview of the Wireless Village Initiative 7

Wireless Village Architecture 8

Wireless Village Primitives 9

Openwaves 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 25TriviaBot 25

BJStrategy Bot 26

TrafficBot 27

Bot Java Classes 29


4/30

Contents



5/30


About This Book

This book provides information for developers tasked with developing applicationsthat will work with Openwaves 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 andexperience with Java and writing Java scripts.

For more information about the IMPS product, refer to the other books in theIMPS documentation set:

For a list of known issues, new features, and the most up-to-date informationon the version of IMPS you are installing, see the Release Notes.

For a general introduction to the IMPS system, its architecture and supportedfeatures 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, seethe Working with the IMPS System.

For conceptual information on agents, clients, and logging as well asdescriptions for each IMPS utility, configuration property, object, attribute,and log event, see the Reference.


6/30

About This Book



7/30

1


1Wireless Village Standards

Conformance

Openwaves IMPS provides a full Service Access Point that conforms with theWireless Village Version 1.1 initiative. IMPS supports all mandatory requirements

of the initiative, as well as some conditional requirements that are applicable toimplementations supporting WAP and SMS client interfaces via HTTP, WirelessSession Protocol (WSP) and SMS transport bindings. This chapter provides detailsregarding the optional requirements that are supported.

Openwaves 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 helpstimulate 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 establishedto define and promote a set of universal specifications for IMPS. This release ofOpenwaves IMPS introduces the implementation of portions of this initiative.

For details on the Wireless Village initiative, seehttp://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 botharound the initiative and through the deployment of innovative new InstantMessaging services. The Wireless Village IMPS includes four primary features:

Presence

Instant Messaging

Groups

Shared Content
http://www.wireless-village.org/http://www.wireless-village.org/


8/30

Wireless Village Standards ConformanceThe Wireless Village Initiative1


Presence includes client device availability, user status, location, client devicecapabilities, and searchable personal statuses such as mood. Access control featuresput the control of the user presence information in the users hands. WirelessVillage enhances the familiar concept ofInstant Messaging by enablinginteroperative mobile IM. Wireless Village allows both operators and end-users to

create and manage groups. Users can invite their friends and family to chat ingroup discussions. Operators can build common interest groups where end-userscan meet each other online. The final feature, Shared Content, allows users andoperators to set up their own storage area where they can post pictures, music, andother multimedia content while enabling the sharing with other individuals andgroups in an IM or chat session.

These features, taken in part or as a whole, provide the basis for new services thatbuild upon a common interoperable frameworkWireless Village.

The Wireless Village specification defines how the IMPS system should interfacewith existing wireless network infrastructures. It also provides an open interface toexisting IM communities on the Internet. To the greatest extent possible, the

protocol uses XML to represent the protocol data being exchanged during an IMPSsession. The architecture and open protocol supports multiple server deploymentssuch that the operator can host their own service, in addition to enabling theenterprise with their own IMPS servers.

Wireless Village Architecture

The Wireless Village server is the central point in the system. It is composed of fourApplication Service Elements that are accessible via the Service Access Point. TheApplication 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) anembedded client and (2) a Command-Line Interface (CLI) client. Each clientcommunicates with the Wireless Village server/system to accomplish IMPS featuresand functions and to provide users with IMPS services.

Interoperability between Wireless Village servers and clients, and between WirelessVillage servers is achieved through the Wireless Village protocol suite. The protocolsuite consists of the Client-Server Protocol (CSP), Server-Server Protocol (SSP),and Command Line Protocol (CLP). The protocol suite runs at the applicationlevel and is compliant with IETF RFC 2778, RFC 2779 and the IMPP CPIMmodel. The Wireless Village protocol suite may run independently over differenttransport layer and bearer protocols.


9/30


Wireless Village Standards ConformanceOpenwaves IMPS Implementation of Wireless Village 1

Wireless Village Primitives

The Wireless Village CSP is composed of primitives, each of which represents asingle function. In other words, a primitive represents a single request from theclient to the server or from the server to the client. For example, a client can send alogin 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 bindingsfor transporting and encoding the data. The allowed transports are HTTP andSMS. 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 aconversation with the server but the server cannot initiate a conversation with theclient), the server must rely on push channels to initiate communication with theclient. The Wireless Village HTTP binding supports three push channels (TCP,UDP, and WAP Push).

Openwaves IMPS Implementation of Wireless VillageThis release of Openwaves IMPS supports a subset of the Wireless VillagePresence, Instant Messaging, and Groups primitives and supports the WirelessVillage Client-Server Protocol (CSP). The supported primitives are listed in thefollowing sections. In addition, Openwave IMPS has extended the Wireless Villageprotocol to accommodate various features of Openwaves IMPS application. SeeChapter 2 for a list of extensions.

The IMPS system supports any Wireless Village client, restricted to the set offeatures indicated in this chapter. The Openwave implementation supports onlyone push channel: TCP (WAP Push and UDP are not supported). The OpenwaveIMPS servers use TCP for pushing to 3G network wireless clients. When

communicating with non-3G wireless clients, the client determines the type ofpush that is used.

General Conformance

Openwaves 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 supportContent Service Element functions.

XML Encoding Requirements IMPS supports both HTTP transport bindingsand conforms to all XML encoding requirements

Address Requirements IMPS does not support client addressing. Local andexternal user addressing are supported.

Session Requirements IMPS supports all session requirements.

Transaction Requirements IMPS supports all transaction requirements.


10/30

Wireless Village Standards ConformanceOpenwaves IMPS Implementation of Wireless Village1


Transport Binding Requirements IMPS provides support for standaloneTCP/IP binding in the Communications Initiation Request (CIR) or pushchannel. No other CIR channel protocol binding is supported. In the datachannel, IMPS supports HTTP and SMS binding, and also supports WirelessSession 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 NSession 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


11/30



Service Access Point Requirements

IMPS provides support for all Wireless Village 1.1 Service Access Pointrequirements except the following:

The Communication Initiation Request primitive is not supported for anyprotocol other than TCP/IP.

IMPS does not return the supported sub protocol version when responding toa 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 forthat protocol binding, and not for CIR over UDP or WAP SMS.

Table 1-2 indicates IMPS support provided for the Service Access Point functions.

With WSP 1.2 or WSP 2.0 bindings for datachannel, only WAP SMS binding or WAP UDPbinding is used in CIR channel.

N/A

SMS binding in data channel (all) Y

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) YStop search Y

Invitation (all) Y

Cancel invitation (all) Y

Table 1-1. General Service Attributes

Requirement Supported?


12/30



Presence Service Element Requirements

The Presence Service element is supported in its entirety for all mandatoryrequirements. Among the optional functional requirements, IMPS supports allexcept the following:

Create, delete, and get attribute list transactions are not supported, nor are anyof the conditional requirements which depend on them.

Get watcher list transactions and their conditional requirements are notsupported.

Table 1-3 indicates IMPS support provided for the Presence Service Elementfunctions.

Instant Messaging Service Element Requirements

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

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


13/30



Among the optional functional requirements for Instant Messaging, IMPS supportsall except the following:

Get list of message transaction is not supported, nor are the conditionalrequirements that depend on it.

Reject message transaction is not supported, nor its conditional requirements.Additionally, certain optional conditional requirements are not supported, even ifthe function itself is supported. These include:

The Openwave IMPS does not switch delivery methods to Notify/Get forMMS messages.

When using the NewMessage primitive, IMPS does not identify the sending clientby Client-ID.

The MessageInfo structure of a GetMessageRequest/Response refers to a messageonly 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


14/30



Group Service Element Requirements

IMPS supports the two mandatory functional requirements for Group ServiceElements: Join Group and Leave Group Transactions. No other functionalrequirements in this category are supported. Table 1-5 indicates IMPS support forthe 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) YMember 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


15/30

2


2Wireless Village Extensions

This chapter provides information on the extensions made to the Wireless Villagestandard that are implemented in Openwaves 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 updatingtyping status.

Subscriber Typing

A user may get/set/unset typing change subscription status. The client sends theSubscribeTypingRequest message to the server. The message contains the type of therequested operation. The answer from the server for the operation is theSubscribeTypingResponse message or Status if an error occurs. While thesubscription is active, the user will receive TypingUserRequest messages. SeeFigure 2-1.

Figure 2-1. Subscriber typing status client-server communication

Client 1 Server

SubscribeTypingResponse

SubscribeTypingRequest

Primitive Direction

SubscribeTypingRequest Client > Server

SubscribeTypingResponse Client


16/30

Wireless Village ExtensionsTyping Indicator Primitives2


Subscriber Typing Request

Information elements used to support the SubscribeTypingRequest extension are (anM indicates it is a mandatory element):

Subscriber Typing Response

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

Updating Typing Status

A user may update their typing status by sending a TypingRequest to the servercontaining and IsTyping element. If the update represents a change in the userstyping status, all users that have enabled typing indicators and have recently beenmessaging with the user will receive a TypingUserRequest. The TypingUserRequestwill contain information identifying the user who is typing and the current state ofthe users typing status. See Figure 2-2.

Information element Required Type Description

MessageType M SubscribeTypingRequest Message identifier

Transaction-ID M String Transaction requestidentifier

Session-ID M String Session identifier

Subscription-State M Enumerated character G for Get,

S for Set,

U for Unset

Information element Required Type Description

MessageType M SubscribeTypingResponse Message identifier

Transaction-ID M String Transaction requestidentifier

Session-ID M String Session identifier

Subscription-State M Boolean Subscription status

indicator


17/30


Wireless Village ExtensionsTyping Indicator Primitives 2

Figure 2-2. Updating typing status client-server communication

Typing Request

Information elements used to support the TypingRequest extension are (an Mindicates it is a mandatory element):

Typing User Request

Information elements used to support the TypingUserRequest extension are (an M

indicates it is a mandatory element):

Client 1 Server Client 2

Status

Status

TypingRequest

TypingUserRequest

Primitive Direction

TypingRequest Client > Server

TypingUserRequest Client


18/30

Wireless Village ExtensionsExtensions to the Wireless Village DTD2


Extensions to the Wireless Village DTD

The following five extensions are made to the Wireless Village DTD:

WBXML Encoding Typing Indicator Token Assignments

WBXML token assignments for typing indicators are listed below. All values are indecimal.

Sender M Structure User or screen name whosetyping state is being sent

IsTyping M Boolean T indicates user is typingF indicates user has stoppedtyping

Code Typing indicator

55 Typing-Request

56 TypingUser-Request

57 SubscribeTyping-Request

58 IsTyping

59 SubscribeTyping-Response


19/30


Wireless Village ExtensionsExtensions to the Wireless Village DTD 2

XML Examples

Typing-Request:

InbandSESSIONID

RequestTRANSACTIONID

wv:[email protected]

TypingUser-Request:

InbandSESSIONID


wv:[email protected]


20/30



SubscribeTyping-Request (get):

Inband

SESSIONID


G

SubscribeTyping-Response (to get):

InbandSESSIONID

ResponseTRANSACTIONID

T

SMS EncodingInformation elements used to support the DTD extensions are:

Element Code

TypingRequest TR

TypingUserRequest TU

SubscribeTypingRequest SY


21/30


Wireless Village ExtensionsExtensions to the Wireless Village DTD 2

SMS Examples

TypingRequest:

WV11TR761 SI=SESSIONID UI=wv:[email protected] IY=T

TypingUserRequest:

WV11TU761 SI=SESSIONID UI=wv:[email protected] IY=T

SubscribeTypingRequest (get):

WV11SY761 SI=SESSIONID SU=G

SubscribeTypingResponse:

WV11YS761 SI=SESSIONID SS=T

SubscribeTypingResponse YS

IsTyping IY


22/30




23/30

3


3Implementing a Bot

Bot, short for robot, is an artificial IMPS user containing logic that dictatesresponses 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 theexample bots provided with the current release, and defines the three base javaclasses implemented to support the definition of bots.

IMPORTANT The example bots are provided for illustrative purposes only. Theyare not expected to be used in a production deployment. No quality assurancetesting on these bots has been performed. Copyright issues may apply in thecase 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 onthe bot function.

2 Create or register a user whose name will be associated with a specific bot. Thiscan be accomplished using the web access wizard.

Bots are associated with a user name, similar to other end users of the IMPSservice. End users access a bot by adding the bot as a buddy, specifying the botuser 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 isdefined in the common.cfg file for the Agent Server.


24/30

Implementing a BotExample Bots3


4 Launch or initialize the bot.

This is typically performed via a cron job or start up script which contains thebot initialization commands. The initialization command should contain aparameter 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 theexample bots, the form used is:

/cloudname/persona/username

For example:

/imps.telco.com/persona/[email protected]

Example Bots

Four example bots are provided for illustrative purposes. Bots are able to maintainthe state of the chat and the number of users interacting with it.

IMPORTANTThe example bots provided are not launched by default. You mustcreate 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 initializationcommand 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 followingdirectory on the Application Server:

$IM_HOME/appserver/apps/botsThe 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.javaChatState.javaChatUser.java./examples/BJStrategy.java./examples/RoShamBot.java./examples/TrafficBot.java./examples/TrafficParser.java

./examples/TriviaBot.javaAdditional files called by these bots can be obtained here:

$IM_HOME/appserver/apps/bots/lib


25/30


Implementing a BotExample Bots 3

RoShamBot

The RoShamBot example implements the game rock-paper-scissors. This botprovides 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 entriesthe users and its ownto 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 andthe RoSham bot is shown below:

?roshambot: 2:32 PMtype: r for rock, s scissors or p for paper {r | s | p}

Player: 2:32 PMrroshambot: 2:32 PMyou: rock, me: rock, RESULT: tie (0 - 0 - 1)Player: 2:32 PMsroshambot: 2:32 PMyou: scissors, me: rock, RESULT: lose (0 - 1 - 1)Player: 2:32 PMproshambot: 2:32 PMyou: paper, me: scissors, RESULT: lose (0 - 2 - 1)Player: 2:32 PM

rroshambot: 2:32 PMyou: rock, me: paper, RESULT: lose (0 - 3 - 1)Player: 2:32 PMrroshambot: 2:32 PMyou: rock, me: rock, RESULT: tie (0 - 3 - 2)Player: 2:32 PMrroshambot: 2:32 PMyou: rock, me: scissors, RESULT: win (1 - 3 - 2)

TriviaBotThe TriviaBot example implements a game of trivia. This bot:

Initiates a game by prompting the user to select from one to nine categories ofquestions:

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


26/30



Replies with the game result, indicating if the user was correct or incorrect, andthe running score

The TriviaBot continues to play the game for a series of ten questions in thecategory chosen. To continue play, the player must enter a ? to start a new game.

A sample listing (from a PC client) showing the interaction between a player andthe trivia bot is shown below:

Player: 4/1/2003 at 5:46 PM?trivia: 4/1/2003 at 5:46 PMChoose set of questions: { #1 | #2 | #3 | #4 | #5 | #6 | #7 | #8 | #9 }Player: 4/1/2003 at 5:46 PM#2trivia: 4/1/2003 at 5:46 PMQ: 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 PM384trivia: 4/1/2003 at 5:46 PMThe answer was 111. 0 out of 1trivia: 4/1/2003 at 5:46 PMQ: In what year did the American Civil War end? { 1776 | 1812 | 1865 |1914 }Player: 4/1/2003 at 5:46 PM1865trivia: 4/1/2003 at 5:46 PMRIGHT! Player got 1865. 1 out of 2

trivia: 4/1/2003 at 5:47 PMQ: What constitutional amendment is the right to bear arms? { 1st | 2nd |18th | 22nd }Player: 4/1/2003 at 5:48 PM2ndtrivia: 4/1/2003 at 5:48 PMRIGHT! Player got 2nd. 5 out of 10trivia: 4/1/2003 at 5:48 PMGame 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: 3player: pair of 4'smove: {s | p | d | h}

It uses a random generator to determine the deal.


27/30


Implementing a BotExample Bots 3

It incorporates the logic of the black jack card game, game rules derived from achart.

Compares the user response with the correct black jack card game strategyresponse

Replies with the game result, indicating if the user was correct or incorrect, andthe running score

The BJStrategy continues to play the game until the player enters quit or reset.

A sample listing (from a PC client) showing the interaction between a player andthe BJStrategy bot is shown below:

dealer: 3player: pair of 4'smove: {s | p | d | h}

Player: 12:27 PMpbjstrategy: 12:28 PMwrong! you should have hit (0 / 1 - 0%)bjstrategy: 12:28 PMdealer: 2player: pair of 6'smove: {s | p | d | h}Player: 12:27 PMpbjstrategy: 12:28 PMwrong! you should have hit (0 / 2 - 0%)bjstrategy: 12:28 PMdealer: 9player: pair of 9's

move: {s | p | d | h}Player: 12:27 PMpbjstrategy: 12:28 PMcorrect (1 / 3 - 33%)bjstrategy: 12:28 PMdealer: 3player: soft 15move: {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. Oneof two highways are used in this example: I90 and HW 405 in the Puget Sound areaof 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 stationsType 'm' to see incident report


28/30



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 eachhighway. Therefore, four user names/persona agents must be defined, one foreach freeway/direction:

520W520E90W90E

The command syntax to initiate the bot is:

TrafficBot [=-]")

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 PMType 'a' to see speed at all stationsType 'm' to see incident report

User: 2:27 PMa

90W: 2:27 PM90W station speeds68 - 23rd Ave S63 - 35th Ave S

96 - West Highrise WB71 - Midspan WB80 - East Highrise WB70 - Isl Crest Way-EB62 - Shorewood Dr64 - E Mercer Way-EB50 - E Channel Bridge45 - 118th Ave SE58 - 118th Ave SE50 - Richards Rd50 - 136th Ave SE61 - 136th Ave SE60 - 136th Ave SE

68 - 161st Ave SE60 - 164th Ave SE55 - 169th Ave SE59 - 182nd Ave SE56 - 188th Ave SE66 - 200th Ave SE62 - 12th Ave NW
http://www.wsdot.wa.gov/PugetSoundTraffic/http://www.wsdot.wa.gov/PugetSoundTraffic/


29/30


Implementing a BotChatState 3

User: 2:27 PMm90W: 2:27 PMTuesday May 07, 2002 + 16:56:15Operator ID : PASKOKHeading : BULLETIN

Message : FOR COMMUTER INFO CALL 206 DOT-HIWY ( 368-4499 )

FOR CURRENT CONSTRUCTION INFORMATION PLEASE VISIThttp://www.wsdot.wa.gov/pugetsoundtraffic/constr.htm

Wednesday Apr 02, 2003 + 13:04:47Operator ID : PASKOKHeading : INCIDENTMessage : INCIDENT INFORMATION ( * = New Incident / Update )CURRENT OPERATOR: Pasko

NO BLOCKING INCIDENTS TO REPORT

Bot Java ClassesThere 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 elementused to define a bot. It represents a connection to a persona and handles all themessage between users and the bot.

When launching a bot, the ChatResponder requires specification of an agentdescriptor. For all bots, this is in the form:

/cloudname/persona/username

For example:

/imps.telco.com/persona/[email protected]

ChatState

Maintains the chat session for a bot.

Discussion The chatState class is optional. It is used when the bot requires maintaining stateinformation for multiple users, such as when a bot maintains a game score.


30/30

Implementing a BotChatUser3

ChatUser

Maintains information on a user in a particular chat. A user may have one of thesepr chat.

Discussion Bots can chat with a number of users. The chatUser class tracks the userinformation, such as their display name, if they are connected, and so on.

Documents

Openwave Imps Developer Guide