Notes on subscriptions

Subscriptions are how users see calendars. A subscription has a name, unique to the owner, some stylistic information, some options and a URI to the calendar.

In the long term subscriptions may be to external as well as internal calendars.

For the ordinary user of the calendar system, who doesn't want to have a complex organization, the ui can probably hide subscriptions to a large extent. For that kind of user calendars appear in their workspace but we don't have to present much of the internals. For example, setting colours can be done directly from an explorer rather than changing a subscription.

Currently, when creating a new subscription, the subscription name defaults to the name of the calendar but should normally be changed - so perhaps we need to remove the default as confusing.

For example: If I subscribe to /user/eric/calendar and /user/johnsa/calendar I don't want two subscriptions called "calendar" because they'll be difficult to distinguish in displays of subscriptiuons so I'd call them something like "erics-calendar" and "arlens-calendar"

I can have two subscriptions to the same calendar in fact. Because stylistic information and other options are included in the calendar I might want two different views which subscribe to the same calendar with diferent options.

That approach may well be useful soon for handling free/busy lookups. Take the case of professor x - he needs to display free busy time to students so they can book office time with him. To students he appears to have little free time. On the other hand, if the Dean is looking he has a lot of free time for meetings. This is going to be handled by a rule based approach which selects a view - e.g a student is authenticated - use the view called 'StudentFreeBusy' the dean is authenticated - use the view called 'MeetingFreeBusy'