Overview

To increase usability of shared applications, it would be beneficial to be able to create a monitor that remotely can connect to a shared application and display application state including name, description, and data as well as current participants and their status (see feature request in Bugzilla, [1]). Ideally, the Application Monitor would also include event logging that would make it possible to display who is doing what, for example, who is changing a web page in the shared browser.

Design

In order to display participant and application information, this have to be stored somewhere accessible for the monitor. The monitor also needs to get updated whenever the application state is changed. With the AppService.py class already containing application state and methods to retrieve the state, minor additions to the AppService would allow us to use this interface for monitoring purposes.

Specifications

Reference Implementation

Sample code can be found in CVS.

Rationale

By adding a client connection ID as parameter to the Join method, information about participants can be retrieved from the Venue and saved in the AppService.py class. The private ID created in the Join method will still act as unique identifier for application clients.

Why not use the client connection ID from the join method as unique app ID?

1. If the client connection ID would be used as unique application ID, a participant can not open more than one shared application client successfully at the same time.
2. To preserve backwards compatibility, the client connection ID parameter in Join can be set to None. Another private ID is then necessary to identify the client.
3. The application monitor should be able to run independently, invisible for people participating in the application session. To achieve this, the monitor would join with client connection ID set to None. Another private ID is then necessary to identify the participant.

Why not use AppParticipantDescription/AppDataDescription as parameters instead of privateId/(dataKey,dataValue)?

To preserve backwards compatibility. For example, the Join method would then return an AppParticipantDescription instead of privateId and that would break old shared applications.

Why creating new descriptions?

The application service has to notify when state information changes in order for a monitor to update properly. Events that are distributed from the event service take a data parameter that can be used for this purpose. Data could be sent as tuples, however, it is easier to document more complex messages that are exchanged between SOAP connections if they are created as description classes.

Why not use SetData for participant status updates?

Participants and their status are something that will be present in all shared applications and can be separated from the data dictionary. If we would remove the SetParticipantStatus method from the interface, it is impossible to tell which data is for status updates and which is not, consequently, making it hard to implement a general application monitor that will work for all shared applications. For example, some application clients might decide to send status as a "status" event, and others as "statusEvent". The application monitor would then have to be re-implemented for each new application.

Interoperability Issues

I removed GetComponents from the interface. Use GetParticipans instead. If this results in problems, it can easily be added again.

.	Old Server	New Server
Old Client	OK	Participants will not show up in monitor. (1)
New Client	Fails (2)	OK

1. Already implemented shared applications will not be affected by the changes described. However, to be displayed as a participant in an application monitor, the shared application has to include a client connection ID when calling the Join method. Also, if more status values other than 'connected' are desired for participants, calls to the SetParticipantStatus method have to be added.
2. New clients calling Join(...) on an old server, will cause an exception. This can be solved by doing a try except on the Join call, if it fails, try to join the application without a parameter.

Open Issues

1. Which IDs do we need for applications? privateId, publicId, connectionId, clientConnectionId and so forth. What should they be used for?

   This is current solution:

   • privateId - Used for the event channel, unique and private to the app client instance.
   • publicId/connectionId - Is created for each app client instance for identification, this ID is public.
   • clientConnectionID - Represents each venue client connection, used for requesting clientprofile from venue.

   Discussion was made if we need both a privateId and a publicId, or if they can be combined into one appID.

2. Should we use other authorization method?

   Currently, the authorization mechanism introduced in the app service is based on the private ID of the application instance:

   if not self.components.has_key(private_token):
      raise InvalidPrivateToken
   

   However, this might be changed to use the same authorization as the rest of the toolkit.

3. Should we implement a heartbeat mechanism that disconnects clients if the application service goes down?

4. Should components include participantdescriptions instead of just public id?

   Currently, components includes participantdescriptions and can be accessed via the GetParticipants call. GetComponents are removed to avoid redundant code.

Overview

If a venue participant does not have a shared application installed, he or she should be able to find a URL to the shared application installer, possibly in the properties of the application (see feature request in Bugzilla, [2]). This would allow a participant to download and install an application to use in the venue.

Design

The ApplicationDescription class currently has an unused description parameter that is shown in the Properties dialog of an application that could be used for this purpose. The Venue Client would open a dialog for adding a description to the application before it is placed under the Application heading. Additionally, the properties dialog for applications, data, and so forth, should be editable.

Implementation

In VenueClientUIClasses

def StartApp(self, app, event=None):
    dlg = AddAppDialog(self, "Add Application", app)
        if dlg.ShowModal() == wxID_OK:
            description = dlg.GetDescription()
            dlg.Destroy()

        else:
            # User canceled, application will not be added
            dlg.Destroy()
            return  

    appDesc = self.app.venueClient.client.CreateApplication( app.name,
                                                            description,
                                                            app.mimeType )  

Overview

Current user scenario for adding applications seem confusing to participants. It is easy to add several shared applications that are named the same, consequently making it hard to know which session to join (see feature request in Bugzilla, [3]).

Design

By allowing participants to re-name a shared application before adding it to the Application heading, the separation of applications would be more obvious. This is a simple UI fix that would let a participant input the application name and change the name parameter in the ApplicationDescription that is created and distributed. The dialog would include both a name and a description field for the application, see earlier discussion about Application Distribution Information.

Implementation

In VenueClientUIClasses

def StartApp(self, app, event=None):
    dlg = AddAppDialog(self, "Add Application", app)
        if dlg.ShowModal() == wxID_OK:
            name = dlg.GetName()
            dlg.Destroy()

        else:
            # User canceled, application will not be added
            dlg.Destroy()
            return  

    appName = app.name + ' - ' + name
    appDesc = self.app.venueClient.client.CreateApplication( appName,
                                                            app.description,
                                                            app.mimeType )  

Note: CreateApp might be a more appropriate name for this method since the application is not actually started.