0.4 Extensibility Proposal
We didn't implement this proposal in .4, the proposal is now obsolete. See
DeveloperPlatformProject for current plans.
Goals
- Packaging and distribution framework (Parcels)
- Items to be loaded into the repository
- Python code associated with the items
- Other resources, also associated with an item: images, etc.
- System for publishing and discovering common resources used by Chandler
- System for publishing and discovering other services
- VOIP services
- spell checkers
Proposal
- We introduce the term Capplet: a particular kind of collection of resources published and discovered together. A Capplet would tend to provide these well known types of resources: Views, Blocks, ContentItem Kinds and Attributes, ScheduledTasks and Actions. We may add other types of resources to that list. A capplet would be a concept that the user was aware of, the user might be able to browse a list of views by capplet. When we have an ApplicationBuilder, the user might be able to browse Blocks or ScheduledTasks by Capplet.
- Code associated with an item in a Capplet has access to the whole repository, including all user data and any items published by parcels. This means that View types defined in one Capplet can use Blocks defined in another, and any ContentItems created by the user. View instances can use Block definitions, Attributes and Kinds from other Capplets -- this creates a dependency on those Capplets.
- Data created by the user (ContentItems) does not belong to any capplet or parcel.
- The selected View controls the application's Chrome, including menu items, sidebar functionality, etc. We expect that all of the Views published in a Capplet would affect the chrome in a similar fashion, so the user might think of Capplets as having different affordances (PIM capplet vs MP3 capplet). A user will have some affordance to "choose" a capplet. This action will choose a well-known View associated with the Capplet, either a default View or the last selected View that belongs to the Capplet.
Division of current code into capplets and parcels
- core parcels
- task manager
- basic content model Kinds and Attributes, including ContentItem, ItemCollection
- basic block definitions
- block instances for the chrome of the application
- pim parcel (capplet)
- pim specific blocks that get inserted into sidebar, for pim specific sidebar behavior
- possibly pim specific content model Kinds and Attributes
- possibly pim specific blocks
- view instances for OOTB views: inbox, etc.
- zaobao parcel (capplet)
- rss content model Attributes and Kinds
- rss view instances
- rss specific blocks, used by the views
- rss loading ScheduledTask definitions and instances
- developer parcel (capplet)
- repository viewer blocks, and view instances using those blocks
- demo block view instance
- smoke test menu items
Scenarios for 3rd party parcels
- MP3 parcel (capplet)
- playlist view types (block definitions)
- OOTB example playlist views
- Block definition for controls that play, pause, stop, etc., to be inserted into sidebar when mp3 summary views are selected. Python code associated with the block to play mp3s.
- content item Kinds and Attributes for song, artist, etc.
- service for playing songs (mp3s)?
- Project management parcel
- gantt chart, other view type and block definitions
- OOTB example views
- content model Kinds and Attributes: new Task Kind, or perhaps a subKind of the PIM capplet Task
- new capplet? new Task Kinds show up in PIM views? new views show up in PIM capplet?
- Book club parcel
- new content model Kinds: book, author, event subKind
- relationships to Contacts, Events
- OOTB example views (uses core summary view block definitions)
- new blocks for detail view?
- new capplet?
- note: its possible that this could be done entirely by the end user at runtime, no parcel involved.
- VOIP functionality
- service for VOIP
- content model additions
- block definitions for use in views
- Mortgage Maker (capplet)
- content model Kinds and Attributes for loan application
- relationships to Contacts, Events, Tasks
- view types and block definitions, and OOTB views that use them
- sidebar?
Open Issues
- We don't strictly need the notion of a capplet, parcels could publish the well known types of resources (Views, Blocks, Kinds and Attributes, etc.) to be discovered. We're proposing a capplet because we think it will be useful to the user to be able to group a set of these well known, user facing items together.
- Assumption: if a user creates a View, it needs to belong to a particular capplet. What consequence does this have?
- The term "capplet" comes from "Chandler applet". Is Chandler a code-name that will go away eventually? If so, is "capplet" a bad term? fyi, "capplet" is a term for Gnome's control panels: http://www.docs.cs.huji.ac.il/RedHat-6.1-guides/rhgsg/gcc.htm
- Are we always "in" a particular Capplet? Can the user ever be in a mode where there isn't a current Capplet? If a non-capplet parcel like a spell checker needs to expose some UI for, say, preferences, or being able to edit a custom dictionary, how is that exposed to the user?
- Do we want to have a standard way for capplets and parcels to expose preference settings? (Think OSX's System Preferences)
- What goes away when you uninstall a Capplet: items dependent on removed python classes? Any custom views that were created within that Capplet? If you upgrade a Capplet, what items/views stay the same and what can change?
- What is consistent about the sidebar from Capplet to Capplet (or from View to View)?
- What UI is there for the user to install, uninstall, upgrade parcels?
- Can we rename parcels to plug-ins, or extensions?
Component framework?
We could extend our goals to cover more of a component framework, where the resources published and discovered are components. We would need to add:
- A mechanism for defining interfaces for components/services
- A mechanism for adapting the interface
Extensibility related terminology
- Parcel? - Parcels are Chandler's components, units of modularity and extensibility. Outside of the core subsystems, most of Chandler is written in Parcels. Third parties will be able to extend Chandler by writing their own Parcels. A Parcel is not necessarily a place that the user "visits" in the UI, but a set of Items? that get loaded into the Repository?. A Parcel might include domain specific schema Items? (Kinds? and Attributes?), items that represent Views?, Agent items, even user data items. A Parcel might also include python code, images, and other resources, referred to by the items in the Parcel.
|
- View? - A View is a kind of CPIA? Block?. Views are the highest level Blocks, so each View is at the root of a tree of Blocks contained in the View.
- See Glossary: Block?
- See Glossary: CPIA?
- See CPIA 0.3 Status?
|
- Block? - A user interface component defined in Chandler's CPIA? architecture.
|
- ScheduledTask - A list of Actions that will be scheduled to run periodically, at a specific time, or based on some event. Examples: the code that fetches email or rss feeds. ScheduledTasks and Actions are building blocks for engineers building Chandler, not end user concepts. Any similar concept exposed to the end user (e.g. Agents) will likely be built using ScheduledTasks.
|
- Content Item - A kind of item in the Chandler Content Model. Content Items are items like Contacts, Calendar Events, Tasks, Mail Messages, and Notes. Content Items are user-level items, which a user might file, categorize, share, and delete.
|
Older Notes
Comments
--
KatieCappsParlante,
MorgenSagen - 29 Apr 2004
Log In