r8 - 30 Oct 2006 - 17:06:16 - PieterHartsookYou are here: OSAF >  Projects Web  >  ScoobyHome > ScoobyPlanning
This page has been moved into the Cosmo Wiki project...


The contents of this page are no longer relevant since Scooby has been incorporated into Cosmo

Scooby 1-year Plan



Scooby is a WebUI exposing the ability to use the Chandler information stored on a Cosmo server through a browser. This document is an extremely rough-draft 1-year plan outlining high-level feature requirements, major technology choices and sequencing decisions. As yet, many of these decisions have not yet been discussed and must be considered strawman decisions (and I welcome input).

To make this plan achievable in 1 year approximately, we plan a 3-4 person Scooby team with

  • 1 Web designer,
  • 1 Web client developer,
  • 1 back-end java developer

We also need people on the team to have a certain amount of product management and project management skills to coordinate within the team.

Comparing Scooby to other calendaring solutions, Scooby is initially (unsurprisingly) rather lightweight. Unlike Exchange with its Outlook Web Access, and Oracle Collaboration suite, Scooby does not present -- even when paired with Cosmo -- a complete workgroup or enterprise collaboration solution. The biggest reason it's not a complete solution is the lack of email support because we intend to rely on existing open source IMAP servers and Email Web access solutions. An organization that wished to use Scooby for basic collaborative calendaring would be able to combine Scooby, Cosmo and other pieces -- probably tying them together via portal integration technology. Note also that Scooby won't initially support many collaborative calendaring features that are considered absolutely required by some enterprises. For example, delegation support isn't in this 1-year plan even though it may be added shortly after.

Issues to resolve/discuss

  • We realize there are some changing requirements from CSG/WAC, particularly surrounding access from mobile devices. Chao, Pieter, Mitch & Lisa are engaging on this topic and there may be some fallout for Scooby. However, new requirements would probably not immediately affect the basic structure of Scooby, particularly phase 1 and 2 of this plan.
  • Work on more detailed plan for hosting capacity (contingencies)... This might relate to issues of navigation and access control

Audience and Use cases

The intended audience for Scooby in phase one and two is supporting individuals and workgroups using Cosmo for sharing or synchronizing calendar data.

  • Some Chandler users will want Scooby for access to their uploaded calendar data when away from their Chandler client.
  • Since use of Chandler is not required to make use of Cosmo and Scooby, some users will use other CalDAV clients (e.g. Sunbird) to synchronize their data with a Cosmo server, and be able to use Scooby when away from their regular client.
  • Some users may not have a rich CalDAV-based client applciation at all. These may be users who only need Web access and not offline functionality, or users who manage their own calendars in paper or in local storage only, and only need Scooby to view other peoples' calendars.

In phase 2 and 3 we will start to provide the user interface constructs needed to scale up for the number of users found in a typical university. There are more challenging access control and navigation problems at that scale than there are at the workgroup scale.

We will develop use cases for each phase, appropriate to these target audiences.

There's somewhat of an exception to these guidelines, in that we'll have to make Scooby work for a single OSAF-hosted server with 1000-10000 users, possibly starting in phase 2, to support our testing and to allow users to experience Chandler sharing and Scooby before committing to installing their own Cosmo/Scooby server. For example, doing actual hosting of thousands of users may require automatically-enforced quota limits on user accounts, even if workgroup use cases don't require that.

Requirements

Functional Requirements Overview

The sequencing plan has more details on how to break down high-level application functions into features and in what order.

Calendaring functions:

  • Allow a user to view his/her own calendar data and that of others who have data on the same Cosmo server.
  • Schedule other users, view their free-busy data.
  • Schedule non-human resources and group calendars.
  • Share via granting access (and rescinding) and sending invitations.

Non-calendaring functions:

  • Expose generic data (including email and tasks) from user's account on the Cosmo server in summary tables or directory listings

Architectural/Technical Requirements

Scooby must work with Cosmo as a back-end. Although our architecture is designed for a certain amount of independence and use of standards in the communication between Scooby and Cosmo (use of WebDAV and JCR), it is not a requirement for Scooby to support other primary back-ends besides Cosmo. An instance of Scooby can be a separate server (or set of servers) from the Cosmo back-end or it can run on the same machine. For this timeframe, Scooby will be configured to use only one Cosmo back-end (only one server URL though it may be handled by multiple machines).

However, Scooby must work with other CalDAV servers and additionally with WebDAV servers hosting iCalendar-based calendars (e.g. those shared via Apple's iCal) such that calendars hosted on those non-Cosmo servers can be viewed by the Scooby user. For example, Katie might host her calendar on a Cosmo repository and view it with Scooby, and overlay her own calendar with friends calendars hosted on Dot Mac (.Mac). We expect to develop and test calendar-reading interoperability with Oracle's Collaboration suite, ISAMET's CalDAV server, Hula, UWCal, .Mac and Slide (as an example of a WebDAV server that can host iCal-shared calendars).

Scooby must be a more responsive WebUI? than was typically feasible in past years (this requirement motivates use of AJAX).

Scooby will support SSL as a configuration option (perhaps the only configuration option). Scooby will use HTTP form authentication over SSL to authenticate users. Unauthenticated users may also be able to view some publicly shared information.

Other

The Scooby UI must be accessible, providing text fallbacks for visual information.

Scooby will only be localized to English. We should however provide the framework for others to do localization, e.g. doing string lookups rather than fixed printed strings.

Scooby will be architected in a way to make rebranding (by editing stylesheets, editing entrance pages, changing images) reasonably easy.

Non-requirements

These are not requirements for Scooby in the first phases. However, many of them are intended for later releases, so we'll keep track of requirements and architectural choices that affect these and try not to hamstring ourselves unnecessarily for future enhancements in these areas.

  • no specialized email functionality. There are already WebUIs? allowing browser access to email servers. People will probably not want to synchronize a lot of mail via Cosmo in the short-term (2 years) so email data won't be directly available to Scooby via Cosmo. Emails that appear in shared/cosmo directories can be viewed but not handled as email (no reply, no send or receive)

  • No specialized task functionality. This might mean that Scooby discards VTODOs when importing an iCalendar file, or stores them but does not offer specialized task views.

  • No specialized contact functionality or hooks to LDAP. This probably means that to send an invitation the user has to know the login or email address of the invitee, rather than pull it from an address book.

  • no support for devices with high limitations in view screen or bandwidth (Palm devices, Win/CE or phones, blackberries). These devices can use WebDAV to get data directly from Cosmo using local programs, or somebody else (or volunteers) can work on limited WebUIs?.

  • no instant notifications of meetings. Support for RSS, email or IM notifications of events is not required.

  • no alarms, as there isn't an easy way to send the alarm to the user. Scooby will attempt to preserve alarm information in calendar events where possible -- e.g. modify existing events stored in Cosmo without overwriting the alarm information.

  • no Trash or Undo -- when an event/task/other is deleted, it's gone.

  • no cross-site search within event text as would be required if we were doing something like EVDB. We will limit search to finding calendars, by searching the calendar name and possibly other limited metadata.

  • No features specialized for public event calendars (we aren't intending to build something like upcoming.org or EVDB).

  • No portal integration required in this timeframe although we will research portlets and other possible technologies for portal integration.

  • No branding configuration work. People running their own instance of Scooby can customize the branding manually.

  • No work to support hosting multiple sites within one instance of Scooby.

  • No work to support client certs in this timeframe.

  • No PIM Dashboard GUI.

Technology

To achieve a higher level of responsiveness, Scooby will use the asynchronous JavaScript and XML back-end data requests that comprise the AJAX architecture.

We expect there will be some cases where Scooby will need to write custom Web widgets or controls, in order to provide the high level of usability to correspond to Chandler's standards. These controls will be developed in JavaScript, hosted by a Scooby server and downloaded as modules that can be used on more than one page.

We use HTTP URLs for two distinct things: for Cosmo resources which are purely data, and for Scooby views which present data together with presentation and client code (and peripherally, Scooby support resources such as stylesheets and scripts). We will sometimes transmit Cosmo URLs (e.g. to Chandler clients, to use for synchronization) and sometimes Scooby URLs (e.g. for non-Chandler users to go to the Scooby WebUI? to view the specified data).

Ideally, Scooby should support Firefox 1.0 (Mac/Win/Lin), Safari 1.3, Internet Explorer 5.2 (Mac and Win). Browser support in Scooby will be determined by a number of factors including browser share among the target audience, and AJAX functionality available.

Sequencing

As a rough plan, we sequence the framework, page and widget development into three phases over 1 year. The phases should correspond to three minor releases although we would like release even more frequently (subdividing the phases).

Phase 1: Basic Calendar Access, minimal sharing

Strictly Calendar functionality

  • Day, week and month views of calendar data, navigation in time
  • Create new events, edit and delete events
  • Handle recurrence
  • Handle user's current timezone (preference) and events with other timezones
  • iCalendar import and export, into user's own calendar
  • Mini calendar control
  • Event date/time select control

Other

  • Display a rough view of non-calendar data in a user's account
  • Rough overall navigation within and between accounts, toolbar and select views
  • Ability to bookmark somebody else's shared collection or calendar.
  • Share whole collection of data with simple ticket access and email invitation
  • Choice to issue either read-only or read-write tickets
  • Sharing termination (revoke ticket)
  • What to do about stamped items?
  • What to do about items which link to other items (e.g. task link to event)?
  • Preferences (timezone, views, change password)

Phase 2: Scheduling and group Calendars

Calendar features

  • Support for delegation on entire calendar -- choose another user identity to grant them the ability
to read/write calendar (without using tickets) and also allows the delegate to grant tickets.
  • Support for delegate to invite people "on behalf of" calendar owner.
  • Support for granting read or read/write privilege to named users on entire calendar.
  • Support an area of group and resource calendars, outside of the user account area.
  • Support for changing the owner of a group or resource calendar.
  • More powerful navigation so that users can find resource and group calendars
  • View free busy -- more than one other user?
  • View multiple calendars?
  • Send scheduling invitations to other users on same server
  • Send scheduling invitations (iMIP) to external addresses
  • Move event between calendars?
  • Include hCalendar scrapable data in event detail and summaries

Other

  • General move/copy/delete resource
  • Ability to create a new calendar or new general sharing collection
  • Handle conflicting changes (ETag changes while resource being edited)
  • Handle event (and task, and contact) attachments -- add, remove, download
  • Storage quota limitations on user accounts

Phase 3: Interop and overlay

Overlay, Interop

  • Search to find local shares or calendars without navigating
  • Add bookmarks or links to other peoples' calendars, local and remote
  • Overlay shared calendars (mine + somebody elses + a public calendars) with events color-coded on the same time view
  • Support other standards-compliant CalDAV servers for read-only access and overlay
  • Support WebDAV+iCalendar shared calendars for read-only access and overlay
  • Internationalization and Accessibility?

Other

  • Paging through large collection contents
  • Searching public calendars, searching a private calendar
  • Research and Develop portal integration plan

Technical issues

  • Where will user preferences be stored? E.g. where will my choice of "default timezone" be stored? Where will the list of calendars I regularly view be stored? What preference information ought to be shared between Scooby and Chandler -- assuming that's even a requirement?

Design issues

  • How will a user view calendars shared to them? By navigating manually each time? By saving bookmarks to calendars they want to see frequently? Or will we have overlays, and if so, which phase? I assume that we don't support navigating to (or bookmarks to, or overlays of) calendars on other servers in the timeframe covered by this plan.

Architectural Issues


This plan was last reviewed Jun 16 2005.

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r8 < r7 < r6 < r5 < r4 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.