Though somewhat independent of BRIDGE, support for efficient, scalable tracking of users activities in needed for many BRIDGE-based apps (conferencing in particular). This involves tracking:
- Who is logged in
- What objects they are accessing
- How long since they were last active (this could be done at a variety of levels -- need to document tradeoffs of client vs. server management of idle info)
Previous systems (VS and MB) gave the client responsibility for both updating awareness information and for cleaning up after clients whose connections had died. The new ...cork.models.userlist.SharedUserList class (and other associated classes) handle the latter task, automatically updating a user list as connections are made and broken.
Remaining issues include:
- Scalability. A single user list (possibly filtered at individual clients) is likely to be acceptible for current systems (e.g., ROLE, navciiti demo systems), but will not scale beyond 10's or 100's of users. Possible solutions to this include:
- Having the client only access per-user "buddy lists" which the server updates from a master list. The master list could be queried to add new users to the buddy list.
- Separating the full user list into smaller lists based on some fixed criteria, e.g., project or organization. (This is really just a variant of (1), with shared, centralized buddy lists.)
- Efficiency. The detail of information that should be passed across the network will vary based on the type of interaction:
- Users who are not working together may not need information beyond present/absent and active/idle
- Users who are working together (or on the same objects, possibly unintentionally) will likely need to know information about which objects are in use.
- Privacy. Providing access to information about current activities is inherently risky. Solutions include:
- Only allowing queries of the form "given that I can access X, who else is accessing X". This could be done with delegated permissions, where information about use of an object is restricted by the same permissions as the object itself.
This type of awareness information is essentially a sparse matrix of users X objects. Exposing a per-user list presents privacy issues, while directly exposing per-object lists presents potentially significant scalability and efficiency issues.
One general approach would be:
- Create a shared table of active objects, mapping each content object id to the id of (another) shared table/list of information about each user who currently has the object open. (This would roughly match the
SharedUserList/SessionData structure.) The table of object session information could have the same permissions as the content object, or could narrow permissions so that anybody who could read the content object could manipulate the object session table.
- The object session table/list could contain the following information:
- User ID
- Time of access
- URL from which the object is accessed
- Name (and iconified state, layer, and bounds?) of window in which the object appears
- Individual clients would still have to be responsible for updating the object session table/list
- The server could be responsible for cleaning up the object session table when a user logs out
- The server could maintain the "master active object table" by:
- Adding an entry to a per-object "accessed" table when a user requests an object. If no object session exists for the requested object, the server could create one and add an entry for it to the table.
- Objects that have not been accessed by any logged-in user could have their session information "cleaned up"
- Scalability issues with the "master active object table" could possibly be handled by:
- Hashing based on the structure of the data. In a system with hierarchical data structure, this might mean traversing up the hierarchy until an EmbeddedObjectDescriptor with a reference to a source of object session tables is found.
- Making the object session tables available through a method in ComponentContext would help hide these details.
Ignoring scalability issues of the "master active object table", this approach would efficiently handle the following cases:
- Presenting information about who was (or how many people were) accessing an object shown in any arbitrary ComponentViewPanel, including such a panel shown in a conference frame.
- Re-inviting a user to a conference that they have exited (e.g., by closing a window or logging out and back in), or getting a remote user's attention if they have iconfied and buried a conference window.
- Presenting information of the form "who is looking at things that I've looked at in this session", possibly available from the user list.
- Generating log information for many of the client-side events that had to be handled explicitly in LiNC (e.g., viewing of a notebook page)
An alternative approach that avoids the "master active object table" would be:
- An ObjectSessionData (OSD) object could could be created when a user logs in, with the ObjectID of the OSD stored in the user's SessionData object. The OSD could be only be readable/writable by the user and the server-side agent that handles SharedUserList manipulation.
- When the user accesses a content object, their client would add an entry describing the access to the user's OSD.
- The server could detect this addition, verify that the user can, in fact, retrieve the object with the given ObjectID, and then scan all other active users to see if anybody else is accessing the object. If they are, then all users' OSDs are synchronized.
- When the user stops accessing the object, the OSDs of all remaining accessors are updated.
This approach trades bandwidth for server cycles. There is no "master list" to be transfered across the net and maintained at each client. The per-access network traffic is roughly equivalent, though no traffic will be generated for objects that are no longer in use at a given client. A fair bit of work must be done by the server to keep the OSDs synchronized, but given that no significant garbage collection is necessary, the total work done by the server may be roughly the same.
|