AGTk 2.2: Simplifying Shared Application Development
In previous columns, I've discussed the facilities provided by the Access Grid™ (AG) Toolkit for developing shared applications. In this column, I'll cover a convenience class included in the 2.2 release that bundles together much of what is needed to develop shared applications. Afterward, I'll provide an example of a shared application that I developed in a couple hours at home.
Shared applications typically join a shared application instance, connect an event client to the shared application event service, register callbacks to handle events and send events. More involved shared applications may require additional functionality, including log application execution, store application state in venue and provide participant info.
The SharedAppClient Class
To address these needs, the AG team constructed the SharedAppClient class. It includes interfaces to provide shared application developers with easy access to the support they need to develop applications as easily as possible. For example, with the SharedAppClient, the single call:
Join(appServiceUrl)
joins the shared application session, creates an event client, and connects the event client to the event service for the shared application. Events can be registered using a simpler method than previously:
RegisterEventCallback(eventType, callback)
where the eventType is defined by the application, and the callback is a method that will be called when an event of the specified type is received by the event client. The callback must accept a single argument: the event that was sent.
Applications can send events by calling the SendEvent method, which takes an application defined event type and data as arguments:
SendEvent(eventType, data)
The SharedAppClient class also provides interfaces for the additional functionality described above:
- Application logging
InitLogging(debug = 0, log = None)
- Storage/retrieval of application state
SetData(dataKey, dataValue)
GetData(dataKey)
- Participant Info, so shared apps can display a list of participants
GetParticipants()
SetParticipantProfile(ClientProfile)
Some of these interfaces are new, while others are simplified to hide details that developers don't need to know. Documentation for the complete SharedAppClient interface is available online at http://www.mcs.anl.gov/fl/research/accessgrid/documentation/devcorner/2004.2/SharedAppClient.html.
The SharedAppClient is being used in the SharedPresentation and SharedBrowser applications for developers to refer to as examples.
Example: SharedGnuplot
Gnuplot is a program widely used for plotting scientific data. It is very straightforward to use: issue plot commands at the prompt and the resulting plot is displayed in a window. For an example of shared application development using the SharedAppClient class, I developed a shared version of Gnuplot.
In this case, when one user inputs a plot command, it is propagated to the other users over the event channel, and executed locally, so that they also see the plot. The example consists of a command processor and a GnuplotSharedAppClient. The command processor is derived from the one found in the Python cmd module. It takes commands, sends them to Gnuplot, and calls a callback registered to deal with commands.
The callback, in this case, is a method in GnuplotSharedAppClient that sends the command to other participants. When this event is received by other clients, the command is sent to their Gnuplot command processor so that the plot is displayed locally.
The command processor is just a front-end to Gnuplot, so it accepts any valid Gnuplot command. There are a couple built-in demo commands included; type 'demo1' or 'demo2' to view interesting sample plots. The example works on both Windows and Linux; on either platform, it requires that the following packages be installed:
The SharedGnuplot package is available at http://www.mcs.anl.gov/fl/research/accessgrid/documentation/devcorner/2004.2/SharedGnuplot.html. It is about 225 lines of code, including comments and the demo command sets, showing how simple it is to develop a shared application for AG.
This example could be easily extended by parsing the Gnuplot commands and performing appropriate venue operations, including storing the current plot state in the venue so latejoining participants see the latest plot, and capturing file-based plot commands to upload the data file to the venue.
If you have any questions or comments about this article, please email me.
—Tom Uram, Argonne, Futures Laboratory, turam@mcs.anl.gov