WimpyPoint II
by Jon Salz
Revision 2 (13 Nov 1999)
Overview
This document outlines the design and implementation strategy planned
for improving WimpyPoint, including (in order of priority):
- Integration with ACS (e.g., fixing naming conventions and using ACS users).
- Allowing authors to freeze presentations, and later view older versions
of the presentation or revert to a previous, frozen version.
- Unlimited length for slide content.
- Allowing files and images to be attached to slides.
- User/group-based access control (ACL lists).
- Implementing data mirroring (copying everything to a backup server
nightly).
- Allowing users to upload and maintain their own style sheets.
- Allowing viewers to override authors' style information.
- User-interface improvements in authoring mode.
Data Model
The tentative new data model is available
here.
It differs
from the old data model in the following ways:
Naming Conventions
All tables will begin with the prefix wp_. This provides
consistency with ACS and will ease migration (see Migration).
ACS Integration
There will be no table specifically tracking WimpyPoint users - instead, we will use
WimpyPoint users and groups.
Access Control
The new wp_user_access and wp_group_access tables describe the set of privileges
available to particular users/groups with respect to a presentation. A user or group may
have
- read access, allowing the user to view the presentation even
if it is not public.
- write access, allowing the user (a "collaborator") to edit the presentation.
- admin access, allowing the user (an "owner") to change the ACL, invite
collaborators, freeze the presentation, delete the presentation, etc.
An administrator can invite another user to collaborate (or co-own the
presentation) by adding him to the ACL list. (WimpyPoint will notify the
invitee via E-mail if requested.) If the user is not already an ACS user
(and thus cannot be added to the ACL), WimpyPoint will issue a "ticket"
(a row in the wp_user_access_ticket) which can be redeemed for
an ACL entry once the account is created. The ticket is protected by a
secret text string which is encoded into the URL sent to the invitee
as part of the invitation request.
Versioning
WimpyPoint will allow authors to freeze presentations,
causing the server to maintain a copy of the current state of the presentation.
To freeze a presentation we set a "checkpoint," causing WimpyPoint to make any future
modifications to any slide in a separate copy. The current checkpoint
ID for a presentation is stored in wp_presentations.checkpoint. Operations
on slides are handled as follows:
- To obtain the most recent version of a slide ss, use a query like
SELECT *
FROM wp_slides sl
WHERE slide_id = ss
AND checkpoint = (SELECT MAX(checkpoint) FROM wp_slides WHERE slide_id = sl.slide_id)
AND deleted_in_checkpoint IS NULL
In other words, we select the row with the maximum checkpoint.
- To obtain the slide as it was when we set checkpoint nn:
SELECT *
FROM wp_slides
WHERE slide_id = ss
AND checkpoint = (SELECT MAX(checkpoint) FROM wp_slides
WHERE slide_id = sl.slide_id
AND checkpoint <= nn)
AND (deleted_in_checkpoint IS NULL OR deleted_in_checkpoint > nn)
Again, we select the row with the maximum checkpoint, this time subject to the constraint
that the checkpoint is nn or earlier (i.e., get the latest change before nn).
Note that these previous two queries are not specific to querying for single
slides; for instance, to view the most resent version of an entire presentation pp,
simply change slide_id = ss to presentation_id = pp and
add ORDER BY sort_key.
- To modify a slide, we check and see if the current version of the slide has checkpoint
set to the most recent checkpoint for the presentation (stored in wp_presentations.checkpoint).
If so, we modify the slide in-place using an UPDATE; if not, a checkpoint has been set since
the last modification so we must create a new row in the wp_slides table referring to the
most recent checkpoint.
- To add a slide, we simply add a row to wp_slides with checkpoint set to the
most recent checkpoint for the presentation.
- To delete a slide (assuming that the current checkpoint for the presentation is cc):
DELETE FROM wp_slides
WHERE slide_id = ss AND checkpoint = cc
UPDATE wp_slides
SET deleted_after_checkpoint = cc
WHERE presentation_id = pp
Images and Attachments
Users will be able to upload images and attachments to display in
slides, either inline or with an explicit link.
Users can upload attachments and images to be displayed inline (embedded
in the page) or separately. These are stored in a separate table
(wp_attachments) so that multiple versions of a presentation can
share them.
Styles
Style information is not limited to a CSS file name - styles will be
stored as rows in the wp_styles table. A style contains
a name, a description, CSS source (included inline when presentations
are displayed), and optionally an owner who can maintain the style.
Users will be able to upload images associated with their style sheets
(stored in wp_style_images).
Individual readers can override authors' style preferences, e.g.,
if the reader prefers black text on white text because he/she needs to
deal with a finicky projector.
Implementation
Implementation steps:
- Migrate the existing code to the new data model (this includes
ACS integration).
- Clean up the authoring interface.
- Add support for versioning.
- Implement unlimited slide length and image/attachment upload.
- Add access control.
- Set up data mirroring (the backup server will run WimpyPoint,
but with editing features disabled).
- Implement the new style management system.
It would also be very cool and useful to allow the user to download a tarball/zipfile
of an entire presentation
(thanks, Richard Tibbets),
but this is really low priority.
All existing presentations will be migrated to the new data model.
We will write a script which:
- Creates an ACS user entry for each WimpyPoint user.
- For each presentation in the old WimpyPoint, reads the
presentation and slides and inserts the appropriate rows
into tables in the new data model, mapping WimpyPoint users
to ACS users, ownership privileges to ACL entries, etc.
This will be fairly easy because the new data model is a functional
superset of the old data model.
jsalz@mit.edu