working notes: will become proposals

Collections

• Item Collection is an abstract base Kind, meant to represent a collection of Content Items.
  • one can treat it as an iterator
  • one can treat it as a list (open issue)
• Query Collection is a subKind of Item Collection, and represents collections that might be created with a query.
  • generic collections are instances of Query Collection.
• Simple Collection is a subKind of Item Collection, and represents collections that are only created explicitly.
  • It is an open issue whether or not we really need a simple collection implementation, or if that behavior can be a special case of the Query Collection.
  • Ad Hoc collections, threads are currently the only uses for Simple Collection.
• Calendar, Project, Mailbox, Spheres of Life, Contact Groups are special kinds of collections, each gets its own Kind. Each is a subKind of Query Collection.

Extensibility

• Capplet: high level unit of extensibility. A capplet may be one type of parcel, or a parcel may contain more than one capplet (open issue). A Capplet is the unit of registration, a capplet publishes different types of items. In particular, a capplet may publish:
  • View: a view comes in at least two flavors, a summary view or a detail view. A summary view is a view of an item collection (a list of content items). A detail view is a view of a particular content item. A capplet is really publishing a "template" of a view.
  • Content Item related Kinds and Attributes: schema information about content items.
  • Data, particular content items: sample data, etc.
  • Block types and python code associated with the block types:
  • Other Kinds, Attributes, python code used for implementation purposes:
  • Tasks, schedules, actions, and associated python code.
• Installation/registration
  • Loading the parcels just puts all of the items in some parcel space, basically the definition of the parcels. One could imagine a future scenario where parcels are loaded not from an xml file on disk but by "sharing" the parcel, although this has security implications.
  • At installation time, view "templates" get installed to the appropriate location. Views are "placed" in an address space, where they can be found by the application.
  • Blocks, Content Model related Kinds and Attributes may also be placed or registered somewhere, so that they may be discovered by the application. (We could discover them using a query for all items for a particular type, but we might want the capplet writer to explicitly note the items to be discovered).
  • Tasks, schedules, actions are registered with the Task Manager.
  • Two distinct phases: "loading" all of the parcels and "installing" the capplet. Implied: one can "uninstall" a capplet, and one can "unload" parcels.
    • Perhaps some core parcels cannot be uninstalled or unloaded.
• Navigation
  • There will be some user affordance for navigating to a Capplet (right now the proposal is to have a drop down box in the sidebar, but we realize this affordance might change). Choosing a Capplet implies choosing a particular view (the last active view in that capplet, or some default).
  • There many affordances for choosing a particular view: clicking on a tab, affordances in the sidebar, affordances in the navigation bar, menus, etc.
  • Each View is associated with one and only one capplet. Each Capplet is associated with many Views, but may have a default or last active View.
  • One view is active at a time. (This is only sort of true, a second or even third view might also be visible, but one is primarily considered active). The active view may alter the contents of the sidebar, the menus, and other parts of the application's chrome. Generally, this modification will be limited to inserting and removing items, the overall behavior of the chrome should remain relatively consistent.
• Tasks
  • do we want a general ui for managing tasks?
    • PIM capplet tasks: email related
    • zaobao: fetching rss feeds

-- KatieCappsParlante - 26 Apr 2004