Specific Google Services Provider for ECF
Google Talk provides more features than standard XMPP (although primarily based on it). Hence, having to use the standard XMPP provider in ECF for communication with Google Talk users is a disadvantage since ECF will not be able to utilize the full potential of Google services which includes voice chat, video chat, off the record chatting, Integration with GMail etc.
Therefore, it will be beneficial for the ECF and the Eclipse community to have a specific Google services provider under ECF, thus enabling the users of ECF to utilize all the services provided by Google Talk.
During the Google Summer Code 2009, the followings requirements will be met:
- Extend the current ECF XMPP Provider to create a specific Google Services provider, with Chat as the first service.
- Implement the following extensions provided by Google Talk:
- Support for user settings handling
- Off the record chatting
- Integration with GMail (receiving email notifications)
- utilize extended contact attributes
- Video chat
- Once Google Voice is available in time, extend the provider to support Google Voice. The following features will be implemented during this program.
- Call initiation
- Screening of calls
- Subscribe to get notifications
- Receive transcripts of voicemails
- Provide UI integration of the Google services provider to the eclipse platform. The UI will be designed with improved user accessibility for all supported features in a more intuitive and user friendly manner.
- A unified UI which will allow access to all the aforesaid communication tasks will be made available.
- Users will be able to invoke tasks by typed commands.For example typing "#file myFile.txt " will send myFile.txt in the current workspace to the contact the user is currently chatting with. The user will be given the freedom to have this option off.
Benefits to the Eclipse Community
ECF gets extended further as a communications platform. Integrated chat, and utilization of Google Services listed above, will be useful for both developers and users of Eclipse platform. There are a number of commercial use cases available.
In addition to that, with the suggested UI and user accessibility improvements such as accessing all features from a unified user interface, and faster methods of accessing the features (typed commands), ECF will get higher user acceptance.
- project design and architecture
- Google Services Provider implementation for ECF
- UI implementation of the provider integrated with Eclipse platform
- Future work will include an RAP implementation of the UI
- Testing report
- User and Developer documentations
There are 2 seperate projects for the complete google services provider:
- org.eclipse.ecf.provider.google - the actual provider
- org.eclipse.ecf.provider.google.ui - UI implementation of the provider integrated with Eclipse platform
Following the lead of the Eclipse Platform, the project architecture makes a very clear distinction between API and internals, placing the latter in packages in the org.eclipse.ecf.provider.internal.google namespace.
The following classes were extended from the respective XMPP provider classes.
IQ stanza handling
Since most of the extensions provided by GTalk rely on IQ stanza based communication between the server and the client, A specific IQ stanza handling mechanism is implemented inside the google provider:
By default, Smack only knows how to process IQ packets with sub-packets that are in a few namespaces such as:jabber:iq:auth, jabber:iq:roster, jabber:iq:register etc. However, smack allows creation of custom IQProviders which will parse custom IQ stanzas accordingly. Therefore, a Generic IQ provider class (GenericIQProvider) was implemented for the google provider. This class is responsible for parsing IQ stanzas which are not recognized by the smack library. The parsed IQ stazas are then processed by the GoogleIQProcessor class which will recognize the IQ stanza (based on the namespaces and IDs) and will take the necessary actions (or will re-direct the IQ packet to the required class).
Notification delegating mechanism
Since there are many notifications that need to shown (when users change the off the record state of chats, email notifications, voicemail notifications etc.) A generic notification handling mechanism is used in the google provider:
NotificationEvent: abstraction of a notification INotificationListener: An interface that need to be implemented by any class interested in receiving NotificationEvents GoogleContainerNotificationManager: Manages the list of registered NotificationListeners and sends notificationEvents to the listeners when a notificationEvent fires.
This notification handling mechanism is utilized by the example UI implementation (xxx.google.ui) through GoogleNotificationUIDelegtor class which implements INotificationListener interface and is registered with the NotificationManager class at the time of view creation for the provider.
- Extended the XMPP provider to create a specific Google Provider.
- created an example ui integration of the google provider to the eclipse platform.
- Hosted the code at []
- A generic IQ stanza receiving and processing mechanism implemented.
- Off the record feature completed
- userhttp://code.google.com/p/google-ecf/s can now switch on/off server side saving of chats
- users get notified when other party changes off the record state
- Shared status messages feature partially complete
- users can retrieve the server stored status message list
I will work on providing an RAP implementation of the completed Google services provider in the future. This will enable users to have access to the functionalities provided by the Google services provider through the web as well.
In addition to that, Google voice integration with the provider will be extended to support more advanced features provided by Google voice.
 [Google Extensions]
 [Google Voice]
 [project repository]