XMPP and SIMPLE: A Comparative Study

Instant messaging and Presence (IMP) is a collection of technologies that create the possibility of near real-time text-based communication between two or more participants over the internet or some form of internal network/intranet. This paper discusses the two major protocols in use for Instant Messaging and Presence: XMPP and SIMPLE. We will also look at the landscape of proprietary IMP protocols currently used in the market as well.

Introduction

There are a number of protocols that have been defined for use in Instant Messaging and Presence applications. Some of them are proprietary and there are also some standardized protocols defined for the same.

This paper explores two prominent standards defined for Instant Messaging and Presence applications, XMPP and SIMPLE. We will also explore the usage of these protocols versus the other proprietary protocols.

Instant Messaging refers to the exchange of text and multimedia messages between two or more parties in near real-time over pubic or private networks. IM is differentiated from email in that email is asynchronous in nature.

IM applications are also integrated with the Presence information of a user. Presence conveys the ability and willingness of a user to communicate across a set of devices. The presence information of a user need not be limited to simple "on-line" and "off-line" status indications. The presence information can be rich and convey mood and privacy and many other attributes as defined for example in RFC 4480 “RPID: Rich Presence Extensions to the Presence Information Data Format”

In the next few sections we will explore two of the open standards that have been defined for IM and Presence applications: XMPP and SIMPLE

XMPP: Extensible Messaging and Presence Protocol

Extensible Messaging and Presence Protocol (XMPP) is an open, XML-based protocol originally aimed at near-real-time, extensible instant messaging (IM) and presence information (e.g., buddy lists), but now expanded into the broader realm of message oriented middleware. It remains the core protocol of the Jabber Instant Messaging and Presence technology. Built to be extensible, the protocol has been extended with features such as Voice over Internet Protocol and file transfer signalling.

History of XMPP

The core technology behind XMPP was invented by Jeremie Miller in 1998, refined in the Jabber open-source community in 1999 and 2000, and formalized by the IETF in 2002 and 2003, resulting in publication of the XMPP RFCs in 2004

More information can be found at http://xmpp.org/about/history.shtml

XMPP Architecture

XMPP uses a distributed architecture. XMPP is generally implemented as client-server architecture. The client using XMPP accesses a server over a TCP connection, and servers also communicate with each other over TCP connections.

Following are the XMPP components:

• Server

The server manages the connections from other entities in the form of streams to and from authorized clients, servers and other entities.

• Client

The client is basically the end user which initiates the streams.

• Gateway

A gateway is a special-purpose server-side service whose primary function is to translate XMPP into the protocol used by a foreign (non-XMPP) messaging system, as well as to translate the return data back into XMPP. Examples are gateways to email, Internet Relay Chat, SIMPLE, Short Message Service, and legacy instant messaging services such as AIM, ICQ, MSN Messenger, and Yahoo! Instant Messenger.

The figure below depicts the XMPP high level architecture.

XMPP Streams and Stanzas

XMPP has two fundamental concepts for the quick, asynchronous exchange of relatively small payloads of structured information between presence-aware entities: XML streams and XML stanzas. These terms are defined as follows:

• Stream

An XML stream is a container for the exchange of XML elements between any two entities over a network. The start of an XML stream is denoted unambiguously by an opening XML <stream> tag (with appropriate attributes and namespace declarations), while the end of the XML stream is denoted unambiguously by a closing XML </stream> tag.

During the life of the stream, the entity that initiated it can send an unbounded number of XML elements over the stream. The "initial stream" is negotiated from the initiating entity (usually a client or server) to the receiving entity (usually a server), and can be seen as corresponding to the initiating entity's "session" with the receiving entity. The initial stream enables unidirectional communication from the initiating entity to the receiving entity; in order to enable information exchange from the receiving entity to the initiating entity, the receiving entity MUST negotiate a stream in the opposite direction (the "response stream").

• Stanza

An XML stanza is a discrete semantic unit of structured information that is sent from one entity to another over an XML stream. The start of any XML stanza is denoted unambiguously by the element start tag at depth=1 of the XML stream (e.g., <presence>), and the end of any XML stanza is denoted unambiguously by the corresponding close tag at depth=1 (e.g., </presence>). An XML stanza may also contain child elements (with accompanying attributes, elements, and XML character data) as necessary in order to convey the desired information. The XMPP standard defines three XML stanzas: <message/>, <presence/>, and <iq/>.

In essence, then, an XML stream acts as an envelope for all the XML stanzas sent during a session. This can be represented as follows:

|--------------------|
| <stream> |
|--------------------|
| <presence> |
| <show/> |
| </presence> |
|--------------------|
| <message to='foo'> |
| <body/> |
| </message> |
|--------------------|
| <iq to='bar'> |
| <query/> |
| </iq> |
|--------------------|
| ... |
|--------------------|
| </stream> |
|--------------------|

Features of XMPP

In this section we will discuss some of the key strengths and weaknesses of XMPP

Strengths:

1. The XMPP protocol is standardized. However proprietary protocols used are not standardized, and work only with the clients and servers that implement that proprietary protocol.

2. The chief difference between XMPP and the proprietary IM networks is that XMPP is decentralized. However proprietary protocols control not only the specification, but the exchange of messages as well. For example, every AIM message is sent to an AOL server before it is sent to the recipient.

3. XMPP is designed to be extensible; new feature sets can be added without breaking the existing protocol. Extensions are managed through an open standards process at the JSF called Jabber Enhancement Proposals (JEP).

4. XMPP allows interworking with proprietary protocols like AOL and ICQ using a federation mechanism implemented via gateways.

Weaknesses:

1. Presence data overhead: A high percentage of XMPP inter-server traffic is presence data and a lot of the data is redundantly transmitted. Hence XMPP currently has a large overhead in delivering presence data to multiple recipients.

2. No binary data: The way XMPP is encoded as a single long XML document makes it impossible to deliver unmodified binary data. Therefore, file transfers use external protocols like HTTP. If unavoidable, XMPP also provides in-band file transfers by encoding all data using base64. Other binary data like encrypted conversations or graphic icons are embedded using the same method.

Market deployments

Based on data gathered by the IMtrends search engine following is an estimate on the deployment percentages for XMPP based servers.

Source: http://www.process-one.net/en/imtrends/article/usage_estimation_of_public_xmpp_servers_per_domain/

SIMPLE

SIMPLE, stands for SIP Instant Messaging and Presence Leveraging Extensions and is an instant messaging (IM) and presence protocol suite based on Session Initiation Protocol (SIP) managed by the IETF. As the name suggest, it is designed for presence and instant messaging. Although it is also XML based (with XML components taken from XMPP for that matter), it is piggybacked on SIP as an event package mechanism.

Like XMPP, and in contrast to the vast majority of IM and presence protocols used by software deployed today, SIMPLE is an open standard.

History of SIMPLE

Simple is a protocol produced by the IETF SIMPLE Working Group. This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The SIMPLE WG has produced a bunch of RFCs to address the requirements of IMP.

The primary focus of the group in on the following:

• Proposed standard SIP extensions documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779, CPIM
• Proposed standard SIP event packages and any related protocol mechanisms used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM.
• Architecture for the implementation of a traditional buddy list based instant messaging and presence application with SIP.

Further information about the SIMPLE WG can be found at:

http://www.ietf.org/dyn/wg/charter/simple-charter.html

SIMPLE Architecture

The SIMPLE architecture is also a distributed architecture with clients, servers and gateways. We will look at the IM and Presence related aspects of the architecture.

Instant Messaging

There are two RFCs defined for Instant Messaging RFC 3428 “SIP Extension for Instant Messaging” and RFC 4975 “Message Session Relay Protocol (MSRP)”

SIP Extension for Instant Messaging (RFC 3428)

This RFC defines the use of the MESSAGE method to exchange instant messages between peer entities.

The MESSAGE method for sending instant messages is similar to a pager mode. There is no explicit association between messages. Each IM is not associated with the other messages exchanged between the two entities. In this sense the concept of a “conversation” only exists in the client user interface. This can be contrasted this with a "session” model, where there is an explicit conversation with a clear beginning and end.

When one user wants to send an instant message to another, the sender generates a SIP request using the MESSAGE method. The Request-URI of this request will normally be the "address of record" for the recipient of the instant message, but it may be a device address in situations where the client has current information about the recipient's location. For example, the client could be coupled with a presence system that supplies an up to date device contact for a given address of record. The body of the request will contain the message to be delivered. This body can be of any MIME type, including message/cpim.

Message Session Relay Protocol (RFC 4957)

The previous section describes a page-mode messaging. Session-mode messaging has a number of benefits over page-mode messaging, however, such as explicit rendezvous, tighter integration with other media-types, direct client-to-client operation, and brokered privacy and security.

RFC 4975 defines a session-oriented instant message transport protocol called the Message Session Relay Protocol (MSRP), whose sessions can be negotiated with an offer or answer using the Session Description Protocol (SDP). The exchange is carried by a signaling protocol, like SIP. This allows a messaging session as one of the possible media-types in a session.

MSRP sessions are typically arranged using SIP the same way a session of audio or video media is set up. One SIP user agent A sends the other B a SIP invitation containing an offered session description that includes a session of MSRP. The receiving SIP user agent can accept the invitation and include an answer session description that acknowledges the choice of media. A's session description contains an MSRP URI that describes where A is willing to receive MSRP requests from B and vice versa.

MSRP defines two request types. SEND requests are used to deliver a complete message or a chunk (a portion of a complete message), while REPORT requests report on the status of a previously sent message, or a range of bytes inside a message.

Messages sent using MSRP can be very large and can be delivered in several SEND requests, where each SEND request contains one chunk of the overall message. Long chunks may be interrupted in mid- transmission to ensure fairness across shared transport connections. To support this, MSRP uses a boundary-based framing mechanism.

This chunking mechanism allows a sender to interrupt a chunk part of the way through sending it. The ability to interrupt messages allows multiple sessions to share a TCP connection, and for large messages to be sent efficiently while not blocking other messages that share the same connection, or even the same MSRP session.

Presence

Presence information is a status indicator that conveys ability and willingness of a user to communicate. A user's client provides presence information (presence state) via a network connection to a presence service, which is stored in what constitutes his personal availability record (called a presentity) and can be made available for distribution to other users (called watchers) to convey his availability for communication. There a whole bunch of

The Presence Architecture as defined by SIMPLE can be described by the following diagram:

A brief description of the different entities is given below:

• Presence source: The presence source (or presentity) is an entity that can provide presence information to a presence server. The presence source can be a user or any entity in the network.
• Presence Server: The presence server is the network entity that stores the presence information published by a presence source and provides the presence information to the watchers
• Watcher: A watcher is an entity that requests information about a presentity
• Resource List Server: A resource list server manages presence lists on behalf of the users

Strengths and weaknesses of SIMPLE

In this section we will discuss some of the key strengths and weaknesses of SIMPLE:

Strengths:

1. The SIMPLE protocol is also standardized by the IETF. Hence there would be a greater incentive for its deployment.

2. SIMPLE defines both a session oriented and a pager mode of operation. This makes the protocol flexible and each application can chooses which variant to implement based on the end-user requirements.

3. The distributed nature of the servers makes the protocol les prone to a single point of failure

Weaknesses:

1. The presence data in SIMPLE being XML based adds a lot of messaging overhead and could potentially consume significant network bandwidth. This can be mitigated by allowing a maximum upper rate at which the UE can publish their data and at which the servers can generate notifications.

Comparison of features in XMPP and SIMPLE

With XMPP and SIMPLE both offering similar capabilities the choice of which protocol to use would depend on the feature offered by each. A good comparison of the features can be found at http://xmpp.org/about/xmpp-simple.shtml

Proprietary IMP Protocols

Besides the SIMPLE and XMPP protocols, there are number of proprietary protocols as well. Following is a brief list of the companies which have their own version of IMP protocols.

• Microsoft Office Communicator
• IBM Sametime
• Yahoo IM
• AOL IM
• Skype

The main reason for each company having their own proprietary protocols is control of the customer. Each company wants to lock their customers into a proprietary protocol which does not inter-work with other protocols, so that users are forced to use the client and servers of that company or service. Hence there is no incentive for them to support the open protocols like XMPP or SIMPLE.

Conclusion

XMPP and SIMPLE provide a similar set of functionality for Presence and IM. Following is a summary of what XMPP and SIMPLE have to offer.

Advantages of using SIMPLE:

• VoIP today mostly uses SIP as the session setup protocol. Hence when deploying SIMPLE, there is no need to develop a new protocol – SIMPLE can use the base SIP software stack and build upon it.
• Since SIMPLE is built on top of SIP, it can enjoy all of the features that SIP provides including authorization, authentication and even compression (SigComp).
• SIMPLE has already been selected for IMS as well. Hence going forward service providers will be using SIMPLE - this includes mobile, cable and fixed networks.

Advantages of using XMPP:

• XMPP is a lightweight protocol – there are a small set of RFCs that need to be implemented for a functional XMPP system. However, since SIMPLE uses SIP, the number of RFCs to be supported is large, and it may be expensive to deploy these stacks on thin clients like mobile devices
• XMPP has been around for a long time and is used by a number IM and presence applications. Hence the penetration of XMPP in the market is higher. For example Google uses XMPP in the GTalk application
• Scale: XMPP based systems can scale better than SIMPLE since XMPP is more lightweight
• Additional features can easily be added via extensions to the protocol which makes it flexible

Considering the points discussed above, both XMPP and SIMPLE will continue to be deployed in the market. There seems to be no clear winner – both will co-exist depending on which application or service is being deployed.

Note that there are also a number of proprietary protocols in use and federation mechanisms will be used in the market to interwork between these variants of IMP protocols. Federation is the process of interworking between the different IM standards, so that users of different IM systems or service providers are able to communicate with each other. This typically involves the use of a gateway server which can convert from one IM format to another. Some examples of federation can be found at the following:

• http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps6837/solution_overview_c22-514646.html
• http://tools.ietf.org/html/rfc5344
• http://tools.ietf.org/html/draft-ietf-simple-intradomain-federation-04

Read More

XMPP and SIMPLE: A Comparative Study

Instant messaging and Presence (IMP) is a collection of technologies that create the possibility of near real-time text-based communication between two or more participants over the internet or some form of internal network/intranet. This paper discusses the two major protocols in use for Instant Messaging and Presence: XMPP and SIMPLE. We will also look at the landscape of proprietary IMP protocols currently used in the market as well.

Introduction

There are a number of protocols that have been defined for use in Instant Messaging and Presence applications. Some of them are proprietary and there are also some standardized protocols defined for the same.

This paper explores two prominent standards defined for Instant Messaging and Presence applications, XMPP and SIMPLE. We will also explore the usage of these protocols versus the other proprietary protocols.

Instant Messaging refers to the exchange of text and multimedia messages between two or more parties in near real-time over pubic or private networks. IM is differentiated from email in that email is asynchronous in nature.

IM applications are also integrated with the Presence information of a user. Presence conveys the ability and willingness of a user to communicate across a set of devices. The presence information of a user need not be limited to simple "on-line" and "off-line" status indications. The presence information can be rich and convey mood and privacy and many other attributes as defined for example in RFC 4480 “RPID: Rich Presence Extensions to the Presence Information Data Format”

In the next few sections we will explore two of the open standards that have been defined for IM and Presence applications: XMPP and SIMPLE

XMPP: Extensible Messaging and Presence Protocol

Extensible Messaging and Presence Protocol (XMPP) is an open, XML-based protocol originally aimed at near-real-time, extensible instant messaging (IM) and presence information (e.g., buddy lists), but now expanded into the broader realm of message oriented middleware. It remains the core protocol of the Jabber Instant Messaging and Presence technology. Built to be extensible, the protocol has been extended with features such as Voice over Internet Protocol and file transfer signalling.

History of XMPP

The core technology behind XMPP was invented by Jeremie Miller in 1998, refined in the Jabber open-source community in 1999 and 2000, and formalized by the IETF in 2002 and 2003, resulting in publication of the XMPP RFCs in 2004

More information can be found at http://xmpp.org/about/history.shtml

XMPP Architecture

XMPP uses a distributed architecture. XMPP is generally implemented as client-server architecture. The client using XMPP accesses a server over a TCP connection, and servers also communicate with each other over TCP connections.

Following are the XMPP components:

• Server

The server manages the connections from other entities in the form of streams to and from authorized clients, servers and other entities.

• Client

The client is basically the end user which initiates the streams.

• Gateway

A gateway is a special-purpose server-side service whose primary function is to translate XMPP into the protocol used by a foreign (non-XMPP) messaging system, as well as to translate the return data back into XMPP. Examples are gateways to email, Internet Relay Chat, SIMPLE, Short Message Service, and legacy instant messaging services such as AIM, ICQ, MSN Messenger, and Yahoo! Instant Messenger.

The figure below depicts the XMPP high level architecture.

XMPP Streams and Stanzas

XMPP has two fundamental concepts for the quick, asynchronous exchange of relatively small payloads of structured information between presence-aware entities: XML streams and XML stanzas. These terms are defined as follows:

• Stream

An XML stream is a container for the exchange of XML elements between any two entities over a network. The start of an XML stream is denoted unambiguously by an opening XML <stream> tag (with appropriate attributes and namespace declarations), while the end of the XML stream is denoted unambiguously by a closing XML </stream> tag.

During the life of the stream, the entity that initiated it can send an unbounded number of XML elements over the stream. The "initial stream" is negotiated from the initiating entity (usually a client or server) to the receiving entity (usually a server), and can be seen as corresponding to the initiating entity's "session" with the receiving entity. The initial stream enables unidirectional communication from the initiating entity to the receiving entity; in order to enable information exchange from the receiving entity to the initiating entity, the receiving entity MUST negotiate a stream in the opposite direction (the "response stream").

• Stanza

An XML stanza is a discrete semantic unit of structured information that is sent from one entity to another over an XML stream. The start of any XML stanza is denoted unambiguously by the element start tag at depth=1 of the XML stream (e.g., <presence>), and the end of any XML stanza is denoted unambiguously by the corresponding close tag at depth=1 (e.g., </presence>). An XML stanza may also contain child elements (with accompanying attributes, elements, and XML character data) as necessary in order to convey the desired information. The XMPP standard defines three XML stanzas: <message/>, <presence/>, and <iq/>.

In essence, then, an XML stream acts as an envelope for all the XML stanzas sent during a session. This can be represented as follows:

|--------------------|
| <stream> |
|--------------------|
| <presence> |
| <show/> |
| </presence> |
|--------------------|
| <message to='foo'> |
| <body/> |
| </message> |
|--------------------|
| <iq to='bar'> |
| <query/> |
| </iq> |
|--------------------|
| ... |
|--------------------|
| </stream> |
|--------------------|

Features of XMPP

In this section we will discuss some of the key strengths and weaknesses of XMPP

Strengths:

1. The XMPP protocol is standardized. However proprietary protocols used are not standardized, and work only with the clients and servers that implement that proprietary protocol.

2. The chief difference between XMPP and the proprietary IM networks is that XMPP is decentralized. However proprietary protocols control not only the specification, but the exchange of messages as well. For example, every AIM message is sent to an AOL server before it is sent to the recipient.

3. XMPP is designed to be extensible; new feature sets can be added without breaking the existing protocol. Extensions are managed through an open standards process at the JSF called Jabber Enhancement Proposals (JEP).

4. XMPP allows interworking with proprietary protocols like AOL and ICQ using a federation mechanism implemented via gateways.

Weaknesses:

1. Presence data overhead: A high percentage of XMPP inter-server traffic is presence data and a lot of the data is redundantly transmitted. Hence XMPP currently has a large overhead in delivering presence data to multiple recipients.

2. No binary data: The way XMPP is encoded as a single long XML document makes it impossible to deliver unmodified binary data. Therefore, file transfers use external protocols like HTTP. If unavoidable, XMPP also provides in-band file transfers by encoding all data using base64. Other binary data like encrypted conversations or graphic icons are embedded using the same method.

Market deployments

Based on data gathered by the IMtrends search engine following is an estimate on the deployment percentages for XMPP based servers.

Source: http://www.process-one.net/en/imtrends/article/usage_estimation_of_public_xmpp_servers_per_domain/

SIMPLE

SIMPLE, stands for SIP Instant Messaging and Presence Leveraging Extensions and is an instant messaging (IM) and presence protocol suite based on Session Initiation Protocol (SIP) managed by the IETF. As the name suggest, it is designed for presence and instant messaging. Although it is also XML based (with XML components taken from XMPP for that matter), it is piggybacked on SIP as an event package mechanism.

Like XMPP, and in contrast to the vast majority of IM and presence protocols used by software deployed today, SIMPLE is an open standard.

History of SIMPLE

Simple is a protocol produced by the IETF SIMPLE Working Group. This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The SIMPLE WG has produced a bunch of RFCs to address the requirements of IMP.

The primary focus of the group in on the following:

• Proposed standard SIP extensions documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779, CPIM
• Proposed standard SIP event packages and any related protocol mechanisms used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM.
• Architecture for the implementation of a traditional buddy list based instant messaging and presence application with SIP.

Further information about the SIMPLE WG can be found at:

http://www.ietf.org/dyn/wg/charter/simple-charter.html

SIMPLE Architecture

The SIMPLE architecture is also a distributed architecture with clients, servers and gateways. We will look at the IM and Presence related aspects of the architecture.

Instant Messaging

There are two RFCs defined for Instant Messaging RFC 3428 “SIP Extension for Instant Messaging” and RFC 4975 “Message Session Relay Protocol (MSRP)”

SIP Extension for Instant Messaging (RFC 3428)

This RFC defines the use of the MESSAGE method to exchange instant messages between peer entities.

The MESSAGE method for sending instant messages is similar to a pager mode. There is no explicit association between messages. Each IM is not associated with the other messages exchanged between the two entities. In this sense the concept of a “conversation” only exists in the client user interface. This can be contrasted this with a "session” model, where there is an explicit conversation with a clear beginning and end.

When one user wants to send an instant message to another, the sender generates a SIP request using the MESSAGE method. The Request-URI of this request will normally be the "address of record" for the recipient of the instant message, but it may be a device address in situations where the client has current information about the recipient's location. For example, the client could be coupled with a presence system that supplies an up to date device contact for a given address of record. The body of the request will contain the message to be delivered. This body can be of any MIME type, including message/cpim.

Message Session Relay Protocol (RFC 4957)

The previous section describes a page-mode messaging. Session-mode messaging has a number of benefits over page-mode messaging, however, such as explicit rendezvous, tighter integration with other media-types, direct client-to-client operation, and brokered privacy and security.

RFC 4975 defines a session-oriented instant message transport protocol called the Message Session Relay Protocol (MSRP), whose sessions can be negotiated with an offer or answer using the Session Description Protocol (SDP). The exchange is carried by a signaling protocol, like SIP. This allows a messaging session as one of the possible media-types in a session.

MSRP sessions are typically arranged using SIP the same way a session of audio or video media is set up. One SIP user agent A sends the other B a SIP invitation containing an offered session description that includes a session of MSRP. The receiving SIP user agent can accept the invitation and include an answer session description that acknowledges the choice of media. A's session description contains an MSRP URI that describes where A is willing to receive MSRP requests from B and vice versa.

MSRP defines two request types. SEND requests are used to deliver a complete message or a chunk (a portion of a complete message), while REPORT requests report on the status of a previously sent message, or a range of bytes inside a message.

Messages sent using MSRP can be very large and can be delivered in several SEND requests, where each SEND request contains one chunk of the overall message. Long chunks may be interrupted in mid- transmission to ensure fairness across shared transport connections. To support this, MSRP uses a boundary-based framing mechanism.

This chunking mechanism allows a sender to interrupt a chunk part of the way through sending it. The ability to interrupt messages allows multiple sessions to share a TCP connection, and for large messages to be sent efficiently while not blocking other messages that share the same connection, or even the same MSRP session.

Presence

Presence information is a status indicator that conveys ability and willingness of a user to communicate. A user's client provides presence information (presence state) via a network connection to a presence service, which is stored in what constitutes his personal availability record (called a presentity) and can be made available for distribution to other users (called watchers) to convey his availability for communication. There a whole bunch of

The Presence Architecture as defined by SIMPLE can be described by the following diagram:

A brief description of the different entities is given below:

• Presence source: The presence source (or presentity) is an entity that can provide presence information to a presence server. The presence source can be a user or any entity in the network.
• Presence Server: The presence server is the network entity that stores the presence information published by a presence source and provides the presence information to the watchers
• Watcher: A watcher is an entity that requests information about a presentity
• Resource List Server: A resource list server manages presence lists on behalf of the users

Strengths and weaknesses of SIMPLE

In this section we will discuss some of the key strengths and weaknesses of SIMPLE:

Strengths:

1. The SIMPLE protocol is also standardized by the IETF. Hence there would be a greater incentive for its deployment.

2. SIMPLE defines both a session oriented and a pager mode of operation. This makes the protocol flexible and each application can chooses which variant to implement based on the end-user requirements.

3. The distributed nature of the servers makes the protocol les prone to a single point of failure

Weaknesses:

1. The presence data in SIMPLE being XML based adds a lot of messaging overhead and could potentially consume significant network bandwidth. This can be mitigated by allowing a maximum upper rate at which the UE can publish their data and at which the servers can generate notifications.

Comparison of features in XMPP and SIMPLE

With XMPP and SIMPLE both offering similar capabilities the choice of which protocol to use would depend on the feature offered by each. A good comparison of the features can be found at http://xmpp.org/about/xmpp-simple.shtml

Proprietary IMP Protocols

Besides the SIMPLE and XMPP protocols, there are number of proprietary protocols as well. Following is a brief list of the companies which have their own version of IMP protocols.

• Microsoft Office Communicator
• IBM Sametime
• Yahoo IM
• AOL IM
• Skype

The main reason for each company having their own proprietary protocols is control of the customer. Each company wants to lock their customers into a proprietary protocol which does not inter-work with other protocols, so that users are forced to use the client and servers of that company or service. Hence there is no incentive for them to support the open protocols like XMPP or SIMPLE.

Conclusion

XMPP and SIMPLE provide a similar set of functionality for Presence and IM. Following is a summary of what XMPP and SIMPLE have to offer.

Advantages of using SIMPLE:

• VoIP today mostly uses SIP as the session setup protocol. Hence when deploying SIMPLE, there is no need to develop a new protocol – SIMPLE can use the base SIP software stack and build upon it.
• Since SIMPLE is built on top of SIP, it can enjoy all of the features that SIP provides including authorization, authentication and even compression (SigComp).
• SIMPLE has already been selected for IMS as well. Hence going forward service providers will be using SIMPLE - this includes mobile, cable and fixed networks.

Advantages of using XMPP:

• XMPP is a lightweight protocol – there are a small set of RFCs that need to be implemented for a functional XMPP system. However, since SIMPLE uses SIP, the number of RFCs to be supported is large, and it may be expensive to deploy these stacks on thin clients like mobile devices
• XMPP has been around for a long time and is used by a number IM and presence applications. Hence the penetration of XMPP in the market is higher. For example Google uses XMPP in the GTalk application
• Scale: XMPP based systems can scale better than SIMPLE since XMPP is more lightweight
• Additional features can easily be added via extensions to the protocol which makes it flexible

Considering the points discussed above, both XMPP and SIMPLE will continue to be deployed in the market. There seems to be no clear winner – both will co-exist depending on which application or service is being deployed.

Note that there are also a number of proprietary protocols in use and federation mechanisms will be used in the market to interwork between these variants of IMP protocols. Federation is the process of interworking between the different IM standards, so that users of different IM systems or service providers are able to communicate with each other. This typically involves the use of a gateway server which can convert from one IM format to another. Some examples of federation can be found at the following:

• http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps6837/solution_overview_c22-514646.html
• http://tools.ietf.org/html/rfc5344
• http://tools.ietf.org/html/draft-ietf-simple-intradomain-federation-04

Read More

rupy - A tiny Java NIO HTTPd (Comet)

Weighing less than 50KB, rupy is probably the smallest Java NIO application server in the world.

Rupy is inherently non-blocking asynchronous, which makes it the ideal candidate for high concurrency real-time applications pushing dynamic data.

Tested with acme, rupy performs on average ~1500 requests per second. To put that figure in perspective; acme doesn't use keep-alive, so that means 1500 unique TCP connections serving dynamic content per second! Thanks to NIO and an event queue to avoid selector trashing, this figure degrades gracefully under high concurrency.

We have started the development of sprout, a simple CMS; based on top of rupy and memory. If you want a real-world example of rupy in action try this out!

Downloads

Comet Chat, JHTML Processor

Read More

rupy - A tiny Java NIO HTTPd (Comet)

Weighing less than 50KB, rupy is probably the smallest Java NIO application server in the world.

Rupy is inherently non-blocking asynchronous, which makes it the ideal candidate for high concurrency real-time applications pushing dynamic data.

Tested with acme, rupy performs on average ~1500 requests per second. To put that figure in perspective; acme doesn't use keep-alive, so that means 1500 unique TCP connections serving dynamic content per second! Thanks to NIO and an event queue to avoid selector trashing, this figure degrades gracefully under high concurrency.

We have started the development of sprout, a simple CMS; based on top of rupy and memory. If you want a real-world example of rupy in action try this out!

Downloads

Comet Chat, JHTML Processor

Read More

GWT Chat Application – (GWT with xmpp protocol)

emite (xmpp & gwt) – This library implements the xmpp communications protocol using the bosh technique with gwt. It also handles the xmpp Instant Messaging protocol but has a modular architecture to support any other kind of communications.

• stable, pure java (no js), portable library
• ready, full featured and easy to use instant messaging implementation
• extensible architecture
• Chat rooms support (Multi-User Chat).
• Other XEP like: Chat State Notifications.
• well tested (junit test, coverage support)

Features :

• Common features support (chat, chat rooms, presence, roster)
• Sound and visual advices when new messages arrive
• Drag & Drop support to start a conversation and for chat room invitations
• i18n support
• Focused in be very usable
• Based in extjs and gwt-ext

Screenshot

emite Chat Demo – click here
emite Chat application download

Read More

GWT Chat Application – (GWT with xmpp protocol)

emite (xmpp & gwt) – This library implements the xmpp communications protocol using the bosh technique with gwt. It also handles the xmpp Instant Messaging protocol but has a modular architecture to support any other kind of communications.

• stable, pure java (no js), portable library
• ready, full featured and easy to use instant messaging implementation
• extensible architecture
• Chat rooms support (Multi-User Chat).
• Other XEP like: Chat State Notifications.
• well tested (junit test, coverage support)

Features :

• Common features support (chat, chat rooms, presence, roster)
• Sound and visual advices when new messages arrive
• Drag & Drop support to start a conversation and for chat room invitations
• i18n support
• Focused in be very usable
• Based in extjs and gwt-ext

Screenshot

emite Chat Demo – click here
emite Chat application download

Read More

Tutorial - Writing Instant Messenger Application - GWT

FYI.. this tutorial is from Google WebToolkit Application Book Author : Ryan Dewsbury

Instant Messenger Application

This tutorial shows how to build the web-based Instant Messenger application. The application is a good example of building on top of a welldefined GWT-RPC interface. Every client that loads the application will connect to a servlet on the server and make method calls through RPC. Each client connects to the same server, so it is possible for clients to collaborate with each other. The chapter also looks at building an unobtrusive user interface that integrates well with an existing web page and that only presents information to the user when necessary. We close the chapter by seeing how events can be added to HTTP using GWT-RPC and how to integrate with server features that make event-based protocols more efficient. You can work with a running instance of this application at http://messenger.gwtapps.com.

Using the Collaborator Application Pattern

Desktop applications are typically written for people working individually. This makes sense since desktop computers only have one person using them at a time. However, in the real world we tend not to work alone but in teams and multiple people have to collaborate on a single document. For example, many document-based applications are single-user based even when certain documents need to be edited by more than one person. Applications typically don’t have a way to manage this type of collaboration. We resort to passing documents through e-mail or copying them to disk. The Collaborator Application pattern addresses the awkwardness of manual collaboration by building collaboration systems directly into the application.

Building collaborative applications is made substantially easier due to the Internet and its pervasiveness. We can fairly simply transfer data from one source to another. Every person who needs to collaborate just must be able to connect to the Internet and use a web browser. It’s important to have low user requirements for collaboration, even more so than for a single- user application, so everyone who needs to be involved can get involved. Traditional web applications have provided a great collaboration platform in this respect, as shown by the popularity of e-mail and other online collaboration applications. The low barrier to entry for Ajax applications can bring richer experiences to web collaboration.

To build an application using the Collaborator pattern you need to define your model as a centralized model that is accessed through a controller, as illustrated in Figure 1. Each collaborative client interacts with the controller to operate on the model. The controller is then responsible for informing the remaining clients of the model changes. You may be thinking that using a collaboration pattern like this can be a challenge for applications that have their communication based on HTTP, because HTTP does not let servers send data to clients without a request being sent by the client. We’ll look at solutions to this problem later in this chapter.

Figure 1

Instant Messenger Design

If you’re reading this tutorial you most likely are familiar with what an instant messenger does. You’ve probably run into them many times and may even use instant messenger services on a daily basis. Their job is to provide instant textual communication between two or more people that is more conversational than e-mail and less intrusive than a phone call. They have been gaining usage with hundreds of millions of users[ Based on a February 2006 comScore survey (www.comscore.com/press/release.asp?id=800) ]. This is a truly successful
desktop Internet application only rivaled by e-mail clients and web browsers. Bringing this type of application into a browser through Ajax provides the added benefits associated with web-based applications: giving people the ability to communicate from anywhere with a web browser without the need to install client software. Furthermore, the ease of running, building, and deploying an Ajax instant messenger means that it can be used easily in many specialized situations without any barriers to entry.

For this sample application we will create a specialized instant messenger for a web page. It will integrate with a web page as an embedded widget complementing the page’s existing purpose with presence [ Presence is an instant messenger feature that provides realtime online status for you and your contacts ] and instant communication among its users. It will accomplish this by providing a contact list that has, instead of a list of friends or colleagues, a list of visitors to the web page. A visitor will be able to supply his name to be added to the list, and then be able to see other visitors and interact with them through instant messages.

Typically with instant messenger systems the clients do not connect directly to each other; instead, they relay messages through a server. Our application will do the same. Figure - 2 shows a simplified illustration of how clients communicate with each other through the server.

When the client loads the web page, the GWT application will be loaded as well and will connect to the server. The user can input a name and then receive events from the server, such as other users viewing the page and coming online or leaving the page, and messages sent from another user.

Figure - 2

Users can also send messages to other users. The server receives these requests and provides responses in a typical request-response behavior, and it also sends events based on these requests to other users using event protocol behavior.

The Instant Messenger server will run as a GWT servlet with a GWT-RPC interface. The clients will connect and make method calls to the servlet to support the instant messenger functionality. The servlet will implement the RPC interface and provide an event broadcasting system to each client. We’ll discuss the event implementation over GWT-RPC later in this chapter.

The application’s internal design follows the Model-View-Controller architecture. The model represents the objects on which the application operates, including the contacts in the contact list and messages. The view presents the contact list and other windows required to render the Instant Messenger on a web page. The controller implements communication with the server and manages model objects to be rendered in the view.

The Model

The Instant Messenger application’s model has three classes: ContactList, Contact, and Message. These classes are very simple and it is easy to suggest that they are not needed in this application; however, one goal of this sample application is to illustrate how to organize your code. If we were building more functionality into this application, we would be putting more data into our model and would find it useful to separate the application’s components.

Another benefit of the model for this application and for the use of GWT for client applications is that we can share our model objects with serverside code. Since we are implementing the server as a servlet, its implementation is also in Java. Furthermore, GWT-RPC allows transferring of Java objects, which lets us use our model objects again for the structure of our protocol’s data.

So let’s look at the structure of the model. If you’re familiar with instant messenger applications, the UML in Figure - 3 seems intuitive.

The ContactList class contains a list of Contacts and a me attribute. This attribute is a reference to a Contact instance that represents the current user. The Contact class has a name attribute representing the contact’s name, and the Message class has a message attribute for the body of the message. These classes can easily be expanded to add functionality to the application. Also notice that the Message and Contact classes implement GWT’s IsSerializable interface. Implementing this interface and creating a no-arg constructor allows their instances to be transferred over the GWT-RPC protocol. As of GWT 1.4 you can use Java’s Serializable interface instead.

These objects are implemented with simple Java code. The following code shows the implementation for the ContactList class:

public class ContactList {
  private Contact me;
  private List contacts = new ArrayList();
  public ContactList( String name ){
  me = new Contact( name );
 }

  public Contact getMe(){
    return me;
 }
  public void addContact( Contact contact){
    contacts.add( contact );
 }
  public int getContactCount(){
    return contacts.size();
 }
 public Contact getContact( int index ){
    return (Contact) contacts.get(index);
 }
}

The class implements what the UML diagram in Figure 9-3 defined. The class provides three methods for the list of contacts: The addContact method inserts a new contact in the list, the getContactCount method returns the number of contacts in the list, and the getContact method returns the contact at a specific index. Now let’s look at the Contact class:

public class Contact implements IsSerializable{
    private String name;
    public Contact(){}
    public Contact( String name ){
      this.name = name;
    }
    public String getName(){
      return name;
    }
}

This is another simple class. It has just one attribute, the contact’s name. This class can be extended to provide more functionality. For example, you could add an e-mail address so that it could be displayed as a link for the user on the page to e-mail other users. Here we see the benefit of the model with this change. The change would be easily available to the controller, the server (since the model will still transfer over RPC), and the view.



The final class in the model is the Message class:

public class Message implements IsSerializable{
private String message;
public Message(){}
public Message( String message ){
this.message = message;
}
public String toString(){
return message;
}
}

Again, this is another simple class in our model. It has just one attribute, the message body. This class can also be easily extended to provide more information, such as adding a timestamp.



Building a Complementary Interface

This application’s view is responsible for presenting users with instant feedback about the presence of other users on the page and their messages. Typically an instant messenger sits hidden in the taskbar of an operating system, or its contact list fits snugly out of the way at the side of the desktop. By contrast, our Instant Messenger application can’t interact with the desktop or a taskbar and has to share space in a browser window. We’ve chosen to implement the messenger as a complement to an existing web page, so it should fit snugly somewhere on the page that does not interfere with the page’s main usage. We will insert the application on the web page based on an HTML element with the ID messengerView, so it is up to the person who implements the web page to define where this element is displayed. Typically it would be displayed in a page’s sidebar, out of the way of the main content, as illustrated in Figure - 4.

Using this defined area for the application is sufficient for logging in with a display name and presenting a list of other users on the page, but we need another view to display and send messages. Again, it is good to follow the example of a desktop messenger here since people are already familiar with this interface. In a desktop instant messenger, a window pops up when another user sends a message. This can be somewhat intrusive since the user could be working on anything on her computer when the window shows up. Some messengers show a nonintrusive toaster-style pop-up in the bottom, right corner of the screen. This pop-up doesn’t take the focus away from what the user is working on, but provides the ability to click it to bring the Chat window to the foreground. In our Ajax version we don’t have to worry too much about interrupting work on the desktop since we can only notify users of an incoming message in the browser window, but we can use the idea of a pop-up in the bottom, right corner to make the notification more familiar to users. Our Chat window will pop up in the bottom, right corner with all the widgets needed to display messages from the other user and send messages to him or her. Figure - 5 illustrates how the Chat window will be displayed in this application.

The pop-up appears in the bottom, right corner and overlaps whatever content is currently at that location. The user can have more than one conversation. When more than one pop-up appears, we will make it appear to the left of the previous one.

The sequence of events that occurs in the application’s view starts with the sign-in view being displayed in the contact list’s location and asking for the user’s display name. After the user provides a sign-in name, the contact list displays, the application starts receiving events from the server, and
the view responds to these events by rendering the model. The first events that the application may receive are new contacts to be displayed in the contact list. Then the view may receive new messages it will display in a Chat window, one per contact. The view can also receive events from the
user, including opening a Chat window by clicking on a contact. The user can enter messages into a Chat window, which the view sends to the controller to send to the server so that the recipient will receive the message.

To provide this functionality we need four view classes. The MessengerView class manages the views in the application, and the SignInView class provides a view for the user to enter a display name. The ContactListView class shows a list of Contacts on the page and allows the user to open Chat windows with each. The ChatWindowView class provides the list of messages for a chat between two contacts and allows the user to send messages. The UML diagram in Figure - 6 shows these classes.

---------pending----------------

Read More

Tutorial - Writing Instant Messenger Application - GWT

FYI.. this tutorial is from Google WebToolkit Application Book Author : Ryan Dewsbury

Instant Messenger Application

This tutorial shows how to build the web-based Instant Messenger application. The application is a good example of building on top of a welldefined GWT-RPC interface. Every client that loads the application will connect to a servlet on the server and make method calls through RPC. Each client connects to the same server, so it is possible for clients to collaborate with each other. The chapter also looks at building an unobtrusive user interface that integrates well with an existing web page and that only presents information to the user when necessary. We close the chapter by seeing how events can be added to HTTP using GWT-RPC and how to integrate with server features that make event-based protocols more efficient. You can work with a running instance of this application at http://messenger.gwtapps.com.

Using the Collaborator Application Pattern

Desktop applications are typically written for people working individually. This makes sense since desktop computers only have one person using them at a time. However, in the real world we tend not to work alone but in teams and multiple people have to collaborate on a single document. For example, many document-based applications are single-user based even when certain documents need to be edited by more than one person. Applications typically don’t have a way to manage this type of collaboration. We resort to passing documents through e-mail or copying them to disk. The Collaborator Application pattern addresses the awkwardness of manual collaboration by building collaboration systems directly into the application.

Building collaborative applications is made substantially easier due to the Internet and its pervasiveness. We can fairly simply transfer data from one source to another. Every person who needs to collaborate just must be able to connect to the Internet and use a web browser. It’s important to have low user requirements for collaboration, even more so than for a single- user application, so everyone who needs to be involved can get involved. Traditional web applications have provided a great collaboration platform in this respect, as shown by the popularity of e-mail and other online collaboration applications. The low barrier to entry for Ajax applications can bring richer experiences to web collaboration.

To build an application using the Collaborator pattern you need to define your model as a centralized model that is accessed through a controller, as illustrated in Figure 1. Each collaborative client interacts with the controller to operate on the model. The controller is then responsible for informing the remaining clients of the model changes. You may be thinking that using a collaboration pattern like this can be a challenge for applications that have their communication based on HTTP, because HTTP does not let servers send data to clients without a request being sent by the client. We’ll look at solutions to this problem later in this chapter.

Figure 1

Instant Messenger Design

If you’re reading this tutorial you most likely are familiar with what an instant messenger does. You’ve probably run into them many times and may even use instant messenger services on a daily basis. Their job is to provide instant textual communication between two or more people that is more conversational than e-mail and less intrusive than a phone call. They have been gaining usage with hundreds of millions of users[ Based on a February 2006 comScore survey (www.comscore.com/press/release.asp?id=800) ]. This is a truly successful
desktop Internet application only rivaled by e-mail clients and web browsers. Bringing this type of application into a browser through Ajax provides the added benefits associated with web-based applications: giving people the ability to communicate from anywhere with a web browser without the need to install client software. Furthermore, the ease of running, building, and deploying an Ajax instant messenger means that it can be used easily in many specialized situations without any barriers to entry.

For this sample application we will create a specialized instant messenger for a web page. It will integrate with a web page as an embedded widget complementing the page’s existing purpose with presence [ Presence is an instant messenger feature that provides realtime online status for you and your contacts ] and instant communication among its users. It will accomplish this by providing a contact list that has, instead of a list of friends or colleagues, a list of visitors to the web page. A visitor will be able to supply his name to be added to the list, and then be able to see other visitors and interact with them through instant messages.

Typically with instant messenger systems the clients do not connect directly to each other; instead, they relay messages through a server. Our application will do the same. Figure - 2 shows a simplified illustration of how clients communicate with each other through the server.

When the client loads the web page, the GWT application will be loaded as well and will connect to the server. The user can input a name and then receive events from the server, such as other users viewing the page and coming online or leaving the page, and messages sent from another user.

Figure - 2

Users can also send messages to other users. The server receives these requests and provides responses in a typical request-response behavior, and it also sends events based on these requests to other users using event protocol behavior.

The Instant Messenger server will run as a GWT servlet with a GWT-RPC interface. The clients will connect and make method calls to the servlet to support the instant messenger functionality. The servlet will implement the RPC interface and provide an event broadcasting system to each client. We’ll discuss the event implementation over GWT-RPC later in this chapter.

The application’s internal design follows the Model-View-Controller architecture. The model represents the objects on which the application operates, including the contacts in the contact list and messages. The view presents the contact list and other windows required to render the Instant Messenger on a web page. The controller implements communication with the server and manages model objects to be rendered in the view.

The Model

The Instant Messenger application’s model has three classes: ContactList, Contact, and Message. These classes are very simple and it is easy to suggest that they are not needed in this application; however, one goal of this sample application is to illustrate how to organize your code. If we were building more functionality into this application, we would be putting more data into our model and would find it useful to separate the application’s components.

Another benefit of the model for this application and for the use of GWT for client applications is that we can share our model objects with serverside code. Since we are implementing the server as a servlet, its implementation is also in Java. Furthermore, GWT-RPC allows transferring of Java objects, which lets us use our model objects again for the structure of our protocol’s data.

So let’s look at the structure of the model. If you’re familiar with instant messenger applications, the UML in Figure - 3 seems intuitive.

The ContactList class contains a list of Contacts and a me attribute. This attribute is a reference to a Contact instance that represents the current user. The Contact class has a name attribute representing the contact’s name, and the Message class has a message attribute for the body of the message. These classes can easily be expanded to add functionality to the application. Also notice that the Message and Contact classes implement GWT’s IsSerializable interface. Implementing this interface and creating a no-arg constructor allows their instances to be transferred over the GWT-RPC protocol. As of GWT 1.4 you can use Java’s Serializable interface instead.

These objects are implemented with simple Java code. The following code shows the implementation for the ContactList class:

public class ContactList {
  private Contact me;
  private List contacts = new ArrayList();
  public ContactList( String name ){
  me = new Contact( name );
 }

  public Contact getMe(){
    return me;
 }
  public void addContact( Contact contact){
    contacts.add( contact );
 }
  public int getContactCount(){
    return contacts.size();
 }
 public Contact getContact( int index ){
    return (Contact) contacts.get(index);
 }
}

The class implements what the UML diagram in Figure 9-3 defined. The class provides three methods for the list of contacts: The addContact method inserts a new contact in the list, the getContactCount method returns the number of contacts in the list, and the getContact method returns the contact at a specific index. Now let’s look at the Contact class:

public class Contact implements IsSerializable{
    private String name;
    public Contact(){}
    public Contact( String name ){
      this.name = name;
    }
    public String getName(){
      return name;
    }
}

This is another simple class. It has just one attribute, the contact’s name. This class can be extended to provide more functionality. For example, you could add an e-mail address so that it could be displayed as a link for the user on the page to e-mail other users. Here we see the benefit of the model with this change. The change would be easily available to the controller, the server (since the model will still transfer over RPC), and the view.



The final class in the model is the Message class:

public class Message implements IsSerializable{
private String message;
public Message(){}
public Message( String message ){
this.message = message;
}
public String toString(){
return message;
}
}

Again, this is another simple class in our model. It has just one attribute, the message body. This class can also be easily extended to provide more information, such as adding a timestamp.



Building a Complementary Interface

This application’s view is responsible for presenting users with instant feedback about the presence of other users on the page and their messages. Typically an instant messenger sits hidden in the taskbar of an operating system, or its contact list fits snugly out of the way at the side of the desktop. By contrast, our Instant Messenger application can’t interact with the desktop or a taskbar and has to share space in a browser window. We’ve chosen to implement the messenger as a complement to an existing web page, so it should fit snugly somewhere on the page that does not interfere with the page’s main usage. We will insert the application on the web page based on an HTML element with the ID messengerView, so it is up to the person who implements the web page to define where this element is displayed. Typically it would be displayed in a page’s sidebar, out of the way of the main content, as illustrated in Figure - 4.

Using this defined area for the application is sufficient for logging in with a display name and presenting a list of other users on the page, but we need another view to display and send messages. Again, it is good to follow the example of a desktop messenger here since people are already familiar with this interface. In a desktop instant messenger, a window pops up when another user sends a message. This can be somewhat intrusive since the user could be working on anything on her computer when the window shows up. Some messengers show a nonintrusive toaster-style pop-up in the bottom, right corner of the screen. This pop-up doesn’t take the focus away from what the user is working on, but provides the ability to click it to bring the Chat window to the foreground. In our Ajax version we don’t have to worry too much about interrupting work on the desktop since we can only notify users of an incoming message in the browser window, but we can use the idea of a pop-up in the bottom, right corner to make the notification more familiar to users. Our Chat window will pop up in the bottom, right corner with all the widgets needed to display messages from the other user and send messages to him or her. Figure - 5 illustrates how the Chat window will be displayed in this application.

The pop-up appears in the bottom, right corner and overlaps whatever content is currently at that location. The user can have more than one conversation. When more than one pop-up appears, we will make it appear to the left of the previous one.

The sequence of events that occurs in the application’s view starts with the sign-in view being displayed in the contact list’s location and asking for the user’s display name. After the user provides a sign-in name, the contact list displays, the application starts receiving events from the server, and
the view responds to these events by rendering the model. The first events that the application may receive are new contacts to be displayed in the contact list. Then the view may receive new messages it will display in a Chat window, one per contact. The view can also receive events from the
user, including opening a Chat window by clicking on a contact. The user can enter messages into a Chat window, which the view sends to the controller to send to the server so that the recipient will receive the message.

To provide this functionality we need four view classes. The MessengerView class manages the views in the application, and the SignInView class provides a view for the user to enter a display name. The ContactListView class shows a list of Contacts on the page and allows the user to open Chat windows with each. The ChatWindowView class provides the list of messages for a chat between two contacts and allows the user to send messages. The UML diagram in Figure - 6 shows these classes.

---------pending----------------

Read More