Child pages
  • Recent Activity Service
Skip to end of metadata
Go to start of metadata

New Concept

  • This is an idea for discussion, please feel free to edit, comment, etc.


This documents a proposed way of tracing recent user activity and user events inside Sakai. In particular this is meant to provide a way to supply various tools with info about user events and activity that users may want to be informed about. This is not meant to prescribe any way of displaying this information to the users. That is left to the designers to decide how to use the data once it is available.

Recent Activity (RA) Service

  • Requirements
    • Store data about user activity for a limited period of time (definable)
    • Allow data to be read out and flushed if desired
    • Allow for easy definition of various user events
  • Interfaces (to answer the following questions)
    • What events have occurred in the past X days in location Y which user Z cares about?
    • What events have occurred in the past X days in location Y?
    • What events have occurred in the past X days which user Z cares about?
  • Creating user events
    • User events would be created as a special type of event which would include added fields and would extend the normal Event type in Sakai
    • Some added information would include: expiration of this event info, release date of this event info, URL for this event data
    • User Event object
      • Extends normal extended event and includes all fields
      • expirationDate - this event information is no longer valuable after this date and should not be shown to users (may be null for no expiration)
      • releaseDate - this event will only be shown to users after this date and will effectively appear to be created at this time (may be null for immediate release)
      • eventURL - this event has a URL which is related to this event, user may be sent to this URL if desired
  • Sample user event creation cycle
    • Tool/Service generates a UserEvent (sent to local only)
    • RA Service has a listener which picks up on the event
    • RA Service registers the event in the user/activity storage
    • RA Service refires the event as a normal distributed event (if the event creator asks for this)
  • Sample Event processing and cleanup cycle
    • RA Service does (configurable) background processing of stored activity
    • Events are expired or rolled up based on a maximum lifetime for events (configurable)
    • Expired events are rolled up into the summary data and individual read/unread flags are lost
  • Sample activity access and lookup
    • Lookup of events for a user will mark those events are read if the the method specifies this should happen
    • Lookup can be told to only include unread events
    • Lookup will generate a list of limited size as desired (pagination support will be built in)
    • Service will be optimized for highly efficient lookups and read flag changes
  • Implementation
    • TODO
  • No labels

1 Comment

  1. Is the idea/concept on this page still actively being pursued, or has it been superseded by other activities or needs?