[Dev] Re: [commits] (capps) [8604] Update to architecture overview
John Anderson
john at osafoundation.org
Tue Dec 13 11:44:19 PST 2005
I reviewed the draft of the 0.6 architecture writeup. Overall, I thought
it was excellent. Feel free to incorporate the following comments if you
think they are appropriate:
In "Data Driven Architecture":
You mention that "The Python code isn't persisted". I think this might
be a little misleading since, when you use a persisted Item, it's
methods are always exists. Perhaps you should say Python code isn't
stored in the repository, or Python code in the application is
automatically associated with Items in the repository, or maybe you
shouldn't mention anything.
Under the description of Collections, you might want to mention that
Collections can be made by combining two or more Collections with
boolean operations. Rather than saying collections use queries, you
might say Collections can contain all the items of a Kind, or filter
another Collection using a Python expression.
In "Data Application Layer":
You might make a distinction between loading all the parcels the first
time -- which should be thought of more like a "build a step" and
loading parcels that were installed after Chandler has already been
run. Even though this isn't always how we ran Chandler today as we
develop, it's important for developers to understand that the repository
always exists and when users typically run Chandler, most parcels were
usually loaded some time in the past. Maybe you could say: Parcels are
not loaded each time you run Chandler, unless they have changed.
The description of how the MainView object gets populated with UI Item
objects seems a bit off. During the initial repository build step, A
tiny topmost tree of blocks rooted at the MainView, some template trees
of blocks, collections, but not including most the UI Items that
eventually get displayed are loaded into the repository. All these are
Items, no different from other Items, loaded from Parcels. After the
repository is built, when the UI is first displayed (i.e. when rendering
the MainView), the BranchPoint Block's controller delegate creates trees
of UI blocks from a combination of code and templates. These trees of
blocks make up most of the UI that is actually displayed.
You might mention the repository viewer as an early "experimental"
parcel, not feature.
In "CPIA":
It wasn't clear in your diagram whether the diagram was supposed to
represent the arrangement of UI on the screen, or the arrangement of
Blocks in the repository. If it's the latter, menu items and toolbar
items can be anywhere in a tree of blocks, not just at the top.
You might mention that the Sidebar contains a Collection of Collections
instead of a list of Collections, and that any number of items can be
selected in the Sidebar instead of just one, however, only one is
displayed in the SummaryViews/DetailView.
In the second paragraph after the first diagram, I'd describe the
typical function of a block as storing the persistent state of the UI
and delegating the display an Item to a widget, and not mention pulling
it from the Repository, since that's an automatic function of all Items.
In the paragraph just after the second diagram (and the one following
it), I would avoid using the term "render", e.g. In the sentence: The
Block delegates the rendering work to a delegate object, called a Widget
because we also use the term render to describe the process of creating
the widget. Perhaps you could say: The Block delegates the work of
display and user-interaction to a delegate object, ...
In the next paragraph, beginning with "Block objects store
information..." you mention that the selection is on the Block. We
recently moved the selection to the Collection (now a
IndexedSelectionCollection, described below) in contents. It contains
the selection and the sort, e.g. order of items in the collection that
is displayed on screen. Now when a single Calendar block is used to
display different contents, each contents has its own selection.
Under "Key decisions" I had never heard of the phrase "We're not trying
to boil the ocean here." After a little googling, it was still unclear,
but my guess is it means trying to solve an intractable problem. Using
CPIA for non-Chandler applications doesn't seem intractable, but
instead, is not an OSAF goal. If people interpret Chandler as a
personal information manager, they might conclude that the CPIA
framework excludes non-PIM content items. Also, CPIA doesn't preclude
interfaces without Sidebars, SummaryViews DetailViews, e.g. the
RepositoryViewer. Perhaps it would make more sense to instead say: OSAF
doesn't intend to use CPIA for any other purpose than building the
Chandler user-interface and allowing for extensions, e.g. extending the
DetailView
Under "Most CPIA code can be found here:" there isn't a SummaryTable
block today. The summary table uses a Table block which is a general
purpose table.
Somewhere nearby the discussion of "The Parcel Developer's Guide to the
Schema API", you might mention that the repository's data model differs
from Python's data model. Notable examples include ref collections,
bidirectional refs, and restrictions on using single refs.
Under "Extension Parcels" the repository viewer and CPIA Viewer are
simple extensions that don't use the SummaryTable or Detail blocks.
In "Threading Model"
The last sentence might be rewritten as follows: As the new changes are
picked up, Blocks are notified about changes to their contents which
caused their Widgets to repaint repaint the affected data in the next
Paint cycle.
In "Collections and Notifications"
You might start with a brief description of each of the different kinds
of Collections:
KindCollection: a collection of all Items of a particular kind
ListCollection: an explicit list of items
DifferenceCollection: a collection that results from the difference of
two source Collections.
UnionCollection: a collection that results from the union of two or more
source Collections
IntersectionCollection: a collection that results from the intersection
of two or more source Collections
FilteredCollection: a collection that contains only those items from
another collection that match a Python filter expression
InclusionExclusionCollection: a compound collection that implements add
by adding items to a unioned, "inclusions" ListCollection, and delete by
adding items to a difference, "exclusion" ListCollection, and always
excludes items in a Trash collection. InclusionExclusionCollection was
implemented as a convenience since most user Collections in the Sidebar
need this functionality.
IndexedSelectionCollection: A collection that adds an index, e.g.for
ordering items in the collection, and a selection for selecting a subset
of the items to source collection. IndexedSelectionCollection allow the
user interface to order and store selections on existing Collections.
As mentioned above, you might replace querying for items with
Collections of all items of a particular kind and filtering another
Collection with a Python expression.
It might be better not to mention Repository Sets in an overview
document since Collections were designed so that you didn't need to know
anything about Repository Sets, which are just an implementation detail
from the API point of view. Also the details of implementation of
Notifications are quite complicated and subject to change. It might be
better to mention that Blocks, when rendered (i.e. displayed on the
screen), that have a contents attribute, will automatically be notified
about changes to their contents in wxWidget's OnIdle processing. Blocks
coordinate with their widget to make sure that changes to the data are
reflected properly on the screen.
The Attribute Editor notification mechanism, using monitors, doesn't
pick up changes from other views, so we will soon switch over to use the
same notification mechanism that we use for Collections today.
John
commits at osafoundation.org wrote:
> Revision
> 8604 <http://viewcvs.osafoundation.org/chandler?view=rev&rev=8604>
> Author
> capps
> Date
> 2005-12-10 17:56:18 -0800 (Sat, 10 Dec 2005)
>
>
> Log Message
>
> Update to architecture overview
> - added text about repository, schema, startup
> - updated layers diagram
>
>
> Modified Paths
>
> * trunk/chandler/distrib/docs/overview-layers.png
> <#trunkchandlerdistribdocsoverviewlayerspng>
> * trunk/chandler/distrib/docs/overview.html
> <#trunkchandlerdistribdocsoverviewhtml>
>
>
> Diff
>
>
> Modified: trunk/chandler/distrib/docs/overview-layers.png
>
>(Binary files differ)
>
>
> Modified: trunk/chandler/distrib/docs/overview.html (8603 => 8604)
>
>--- trunk/chandler/distrib/docs/overview.html 2005-12-10 23:54:36 UTC (rev 8603)
>+++ trunk/chandler/distrib/docs/overview.html 2005-12-11 01:56:18 UTC (rev 8604)
>@@ -2,59 +2,28 @@
> <html>
> <head>
>
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
> <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
>+ <title>Chandler 0.6 Architecture</title>
>
>
>-
>-
>-
>-
>-
>-
>-
>-
>- <title>Chandler 0.6 Architecture</title>
> </head>
>
>
> <body>
>
>-
>-
>-
>-
>-
> <h1>Chandler Architecture (0.6 Release)</h1>
>
>+<h3>Introduction</h3>
>
>-
>-
>-
>-<h3>Overview</h3>
>-
> This document gives a brief overview of Chandler's architecture.
>- We'll explain some fundamental concepts to understand Chandler as
>+ We'll explain some fundamental concepts to understand
>+Chandler as
> a data driven architecture. We'll describe Chandler's layers,
> introduce Chandler-specific terminology, and give high
> level overviews of important aspects of the architecture. <br>
>
> <br>
>
>-
>-
>-
>-
>-
> Chandler is a work in progress; we are still working out both bugs in
> the code that don't conform to the architecture, as well as "bugs" or
> problems with the architecture itself. This document is an effort to
>@@ -74,7 +43,7 @@
>
> <a href="#Domain_Model">Domain Model</a><br>
>
>-<a href="#Schema">Schema</a><br>
>+<a href="#Parcel_Framework">Parcel Framework</a><br>
>
> <a href="#Repository">Repository</a></div>
>
>@@ -84,106 +53,77 @@
>
> <a href="#Security">Security</a><br>
>
>-<a href="#Collections_and_Notifications">Collections and Notifications</a><br>
>+<a href="#Collections_and_Notifications">Collections and
>+Notifications</a><br>
>
> <a href="#Threading_Model">Threading Model</a><br>
>
> <a href="#Threading_Model">Discovery and Startup</a><br>
>
>+<h2><a name="Data_Driven_Architecture"></a>Data
>+Driven Architecture</h2>
>
>+Before we start describing Chandler's layers, we need to introduce a
>+few concepts: <span style="font-weight: bold;">Items</span>,
>+<span style="font-weight: bold;">Kinds</span>, <span style="font-weight: bold;">Attributes</span>, <span style="font-weight: bold;">Collections</span>, the <span style="font-weight: bold;">Repository</span> and <span style="font-weight: bold;">Parcels</span>. These
>+concepts are a consequence of Chandler's data driven architecture, and
>+pervade the system.<br>
>
>-
>-
>-<h2><a name="Data_Driven_Architecture"></a>Data Driven Architecture</h2>
>-
>-
>-
>-
>-
>-
>-Before we start describing Chandler's layers, we need to introduce a few concepts: <span style="font-weight: bold;">Items</span>, <span style="font-weight: bold;">Kinds</span>, <span style="font-weight: bold;">Attributes</span>, <span style="font-weight: bold;">Collections</span>, the <span style="font-weight: bold;">Repository</span> and <span style="font-weight: bold;">Parcels</span>. These concepts are a consequence of Chandler's data driven architecture, and pervade the system.<br>
>-
>-
>-
>-
>-
> <br>
>
>+The fundamental unit in Chandler is an <span style="font-weight: bold;">Item</span>. An Item is a
>+Python object that it can be persisted to Chandler's <span style="font-weight: bold;">Repository</span>. An Item
>+is defined by its <span style="font-weight: bold;">Kind</span>.
>+A Kind describes information about a whole class of Items, and is
>+implemented as a Python class. Items have <span style="font-weight: bold;">Attributes</span>, just
>+like Python objects. The Item's Kind defines these Attributes.
>+ For example, a <span style="font-family: monospace;">CalendarEvent</span>
>+is a Kind, with the Attributes <span style="font-family: monospace;">startTime</span> and <span style="font-family: monospace;">summary</span>. Once
>+the user has created an event on her calendar, <span style="font-family: monospace;">"Lunch with Mitch</span>"
>+is an Item, a persistent object stored in the repository. <span style="font-family: monospace;"></span><br>
>
>-
>-
>-
>-The fundamental unit in Chandler is an <span style="font-weight: bold;">Item</span>. An Item is a Python object that it can be persisted to Chandler's <span style="font-weight: bold;">Repository</span>. An Item is defined by its <span style="font-weight: bold;">Kind</span>. A Kind describes information about a whole class of Items, and is implemented as a Python class. Items have <span style="font-weight: bold;">Attributes</span>, just like Python objects. The Item's Kind defines these Attributes. For example, a <span style="font-family: monospace;">CalendarEvent</span> is a Kind, with the Attributes <span style="font-family: monospace;">startTime</span> and <span style="font-family: monospace;">summary</span>. Once the user has created an event on her calendar, <span style=!
> "font-family: monospace;">"Lunch with Mitch</span>" is an Item, a persistent object stored in the repository. <span style="font-family: monospace;"></span><br>
>-
>-
>-
>-
>-
> <br>
>
> Much work in Chandler is done by creating Item objects and populating
> the Item's attributes. Examples of Items include calendar
> events, email messages and tasks -- what we might think of as user
>-data. UI objects like menus and views are also stored as Items,
>+data. UI objects like menus and views are also stored as
>+Items,
> as are services like the background task that fetches email. Under the
> hood, the Kinds that describe these Items
>-(e.g. MailMessage, Menu, PeriodicTask) are also persisted to
>+(e.g. MailMessage, Menu, PeriodicTask) are also
>+persisted to
> the Repository
> as Items. (Well, the Python code isn't persisted, but meta-data that
> describes these Kinds is persisted). <br>
>
>-
>-
>-
>-
> <br>
>
>-Most Chandler code is in the form of Python classes that implement
>+Most Chandler code is in the form of Python classes that
>+implement
> a Kind. These Python classes define the Kind's Attributes and implement
> methods associated with that Kind. Because the terminology can be
> confusing, in this document we'll often say
> "class" or "Python class" instead of using the term "Kind".<br>
>
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
>-A <span style="font-weight: bold;">Collection</span> is a set of
>+A <span style="font-weight: bold;">Collection</span>
>+is a set of
> Items. A Collection is an Item itself. It can define the set of
> Items by explicitly listing the items, with a query, or by combining
> two other sets of items. Collections play a key role in Chandler's
> architecture, discussed in more detail below in <a href="#Collections_and_Notifications">Collections</a>.<br>
>
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
>-In Chandler, Item object definitions and Kind class definitions are defined in <span style="font-weight: bold;">Parcels</span>.
>+In Chandler, Item objects and Kind classes are
>+defined in <span style="font-weight: bold;">Parcels</span>.
> Parcels are Python packages and modules that are introspected at
>-startup so that Item and Kind data can be loaded into the Repository. <br>
>+startup so that Item and Kind data can be loaded into the Repository.<br>
>
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> Most Chandler code lives in Parcels. The few exceptions to this are the
> subsystems needed to bootstrap the system -- the repository itself,
> wxPython related startup code, and some services used by the repository
>@@ -201,88 +141,51 @@
> pull up the appropriate code to view or manipulate the Item, based on
> its Kind.<br>
>
>-
>-
>-
>-
>-
> <h2><a name="Layers"></a>Layers</h2>
>
>+We will now look at each of the layers that make up the Chandler
>+architecture. <br>
>
>-
>-
>-
>-
>-We will now look at each of the layers that make up the Chandler architecture. <br>
>-
>-
> <h3><img style="width: 500px; height: 724px;" alt="architecture layers" src="overview-layers.png">
>-
>-
>-
> </h3>
>
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> Generally, each layer or component is able to directly access the
> APIs of the layers below it. The lower level layers communicate to the
> layers above via a system of notifications. The lower level layers
> should have no specific knowledge of the layers above, and the higher
> level layers should know only the APIs of the layers below.<br>
>
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
>-Chandler uses a variant of a Model -View - Controller architecture. Like
>+Chandler uses a variant of a Model -View - Controller architecture.
>+Like
> many applications built on GUI frameworks, Chandler tends to mix the
>-View and Controller code in one layer. We expect to reexamine this choice in
>+View and Controller code in one layer. We expect to reexamine this
>+choice in
> the 0.7 timeframe -- this document will focus on the code as it exists
> in the 0.6 release.
>-<h3><a name="Application_Layer"></a>Application Layer</h3>
>+<h3><a name="Application_Layer"></a>Application
>+Layer</h3>
>
>-
>-
>-
>-
> The application layer is the topmost layer and responsible for pulling
> all of the pieces together to present the interface to the user. It has
> the role of a Controller in terms of an MVC architecture.<br>
>
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> The application layer handles the startup of Chandler. It contains the
> main "application" class that is primarily responsible for
>-initializing Chandler components, as well as populating the <span style="font-weight: bold;">MainView</span> object that describes the layout of the application.<br>
>+initializing Chandler components, as well as populating the <span style="font-weight: bold;">MainView</span> object that
>+describes the layout of the application.<br>
>
>-
>-
>-
>-
> <br>
>
>-The Chandler application is built on wxPython, a cross platform GUI toolkit. wxPython is a python wrapper on top of <a href="http://www.wxwidgets.org/">wxWidgets</a>. wxWidgets provides a uniform C++ API on top of native toolkits: GTK, Win32 and OSX (Carbon).<br>
>+The Chandler application is built on wxPython, a cross platform GUI
>+toolkit. wxPython is a python wrapper on top of <a href="http://www.wxwidgets.org/">wxWidgets</a>.
>+wxWidgets provides a uniform C++ API on top of native toolkits: GTK,
>+Win32 and OSX (Carbon).<br>
>
> <br>
>
>@@ -293,19 +196,12 @@
> method loads all
> of the Parcels and commits Items defined in the parcels to the
> Repository. It also kicks off Twisted, which manages the networking
>-services. (See <a href="#Services">Services</a> and <a href="#Threading_Model">Threading Model</a>). <br>
>+services. (See <a href="#Services">Services</a>
>+and <a href="#Threading_Model">Threading Model</a>).
>+<br>
>
>-
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> The MainView object gets populated with UI Item objects defined
> in lower layers: what the menus are, where the sidebar goes, how much
> space the detail view takes, etc. It also creates well
>@@ -313,109 +209,49 @@
> event handlers for
> application-wide events (e.g. Quit, "New Collection"). <br>
>
>-
>-
>-
>-
> <h5>
> Most application layer code can be found here:</h5>
>
>-
>-
>-
>-
> <ul>
>
>+ <li style="font-weight: bold;">Chandler.py <span style="font-weight: normal;">The starting point for the GUI
>+application.</span></li>
>
>+ <li style="font-weight: bold;"><span style="font-weight: normal;"><span style="font-weight: bold;">tools.headless</span> The
>+starting point for running Chandler as a server with no GUI. </span></li>
>
>-
>-
>- <li style="font-weight: bold;">Chandler.py <span style="font-weight: normal;">The starting point for the GUI application.</span></li>
>-
>-
>-
>-
>-
>- <li style="font-weight: bold;"><span style="font-weight: normal;"><span style="font-weight: bold;">tools.headless</span> The starting point for running Chandler as a server with no GUI.
>-
>-
>-
>- </span></li>
>-
>-
>-
>-
>-
>- <li style="font-weight: bold;">
>-application<span style="font-weight: normal;"> The
>+ <li style="font-weight: bold;">application<span style="font-weight: normal;"> The
> main class that runs the wxPython app, including application startup
> code. Also includes wxPython related printing support, and some system
> wide global variables.</span></li>
>
>-
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-application.dialogs</span>
>+ <li><span style="font-weight: bold;">application.dialogs</span>
> wxPython dialogs used by the application. Eventually these may get
> moved into CPIA, but currently don't fully conform to the architecture.</li>
>
>-
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-parcels.osaf.views.main</span>
>+ <li><span style="font-weight: bold;">parcels.osaf.views.main</span>
> The definition of the MainView, the highest level block that describes
> the layout of the application. Also contains most of the applications
> menus, events, and event handlers.</li>
>
>+ <li><span style="font-weight: bold;">parcels.osaf.app</span>
>+Well known items, including well known collections and default account
>+information</li>
>
>+ <li><span style="font-weight: bold;">parcels.osaf.app.scripts</span>
>+Example scripts</li>
>
>+ <li><span style="font-weight: bold;">parcels.osaf.views.repositoryviewer</span>
>+The repository viewer is an early "experimental" feature, accessible
>+from the test menu.</li>
>
>+ <li style="font-weight: bold;">parcels.osaf.views.demo, parcels.osaf.views.cpiatest<span style="font-weight: normal;"> Test code that
>+exercises CPIA.</span></li>
>
>- <li><span style="font-weight: bold;">
>-parcels.osaf.app</span> Well known items, including well known collections and default account information</li>
>-
>-
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-parcels.osaf.app.scripts</span> Example scripts</li>
>-
>-
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-parcels.osaf.views.repositoryviewer</span> The repository viewer is an early "experimental" feature, accessible from the test menu.</li>
>-
>-
>-
>-
>-
>- <li style="font-weight: bold;">
>-parcels.osaf.views.demo, parcels.osaf.views.cpiatest<span style="font-weight: normal;"> Test code that exercises CPIA.</span></li>
>-
>-
>-
>-
>-
> </ul>
>
>-
>-
>-
>-
>-
> <h3><a name="CPIA"></a>CPIA</h3>
>
>-
>-
>-
>-
> CPIA stands for Chandler Presentation and Interaction Architecture. It
> blends the role of View and Controller in an MVC architecture. CPIA
> is intended to be a Chandler specific framework, so it has API
>@@ -434,25 +270,22 @@
>
> <br>
>
>-Chandler has a familiar three pane view. The <span style="font-weight: bold;">Sidebar</span> contains a list of Collections, and one of them is selected. The <span style="font-weight: bold;">Summary View</span> displays the Items in the Collection, and one Item is selected. The <span style="font-weight: bold;">Detail View</span> displays the selected Item. The <span style="font-weight: bold;">Application Bar</span>
>+Chandler has a familiar three pane view. The <span style="font-weight: bold;">Sidebar</span> contains a
>+list of Collections, and one of them is selected. The <span style="font-weight: bold;">Summary View</span>
>+displays the Items in the Collection, and one Item is selected. The <span style="font-weight: bold;">Detail View</span> displays
>+the selected Item. The <span style="font-weight: bold;">Application
>+Bar</span>
> determines the application mode, which is used to filter what Kinds of
> Items are displayed and what type of Summary View is used. In calendar
> mode, for example, collections of Calendar Events can be seen in a
> Calendar View. The application also has other common elements: <span style="font-weight: bold;">Menus</span>, a <span style="font-weight: bold;">Toolbar</span>, and a <span style="font-weight: bold;">Status Bar</span>. <br>
>
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
>-
>-CPIA's role is to provide building blocks for Chandler's user interface, including
>-some generic building blocks (e.g. Menus, Status Bar) as well as more Chandler
>+CPIA's role is to provide building blocks for Chandler's user
>+interface, including
>+some generic building blocks (e.g. Menus, Status Bar) as well as more
>+Chandler
> specific building blocks (e.g. Sidebar, Calendar View,
> Detail View). Because we think of them as building blocks, the core
> unit in CPIA is called a <span style="font-weight: bold;">Block</span>.<br>
>@@ -462,7 +295,8 @@
> The typical function of a Block is to pull an Item or Collection from
> the Repository and display it to the user. A
> Block also takes input from the user, committing edits to the Item
>-back to the Repository. Blocks can contain other Blocks,
>+back to the Repository. Blocks can contain
>+other Blocks,
> which you can think of as a tree of
> blocks. The Main View is the complete tree of blocks that describes the
> layout of Chandler. (We sometimes use "Block" and "View"
>@@ -473,10 +307,6 @@
> The appropriate Detail View tree of blocks gets hooked into the Main
> View, depending on the Kind of Item selected.<br>
>
>-
>-
>-
>-
> <br>
>
> The CPIA layer defines the Block classes. The application layer creates
>@@ -487,13 +317,10 @@
> in the Repository will someday enable us to build a cool UI builder,
> but that is a future project).<br>
>
>-
>-
>-
>-
> <br>
>
>-The Block class primarily defines data about the UI element -- the
>+The Block class primarily defines data about the UI element --
>+the
> data that persists to the Repository. A calendar block object, for
> example, might know about the collection of items displayed, the
> currently selected item, and the currently selected date range. The
>@@ -503,65 +330,38 @@
> they are not Items and they do not persist to the Repository). Each
> Block object has a peer Widget object, as in the diagram below:<br>
>
>-
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> <img style="width: 383px; height: 341px;" alt="cpia block and widget" src="overview-cpia.png"><br>
>
>-
>-
>-
>-
>-
> <br>
>
> The Block knows about its "contents", which is usually an Item or
> Collection in the domain model (e.g. "All my items" collection, or
>- a "Lunch with Mitch" calendar event). The Block hands
>+ a "Lunch with Mitch" calendar event). The Block
>+hands
> the Item or Collection to the Widget to do the actual
> rendering. <br>
>
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> Another key concept in CPIA is that of an <span style="font-weight: bold;">AttributeEditor</span>.
> Attribute editors are Python classes that handle the editing and
> rendering of one Attribute of one Item. Attribute editors are used by
> the DetailView or the SummaryTableView to render and edit a selected
> Item's attributes. For example, if a CalendarEvent is selected in the
> DetailView, a date-time attribute editor handles the editing and
>-rendering of the <span style="font-family: monospace;">startTime</span>, and a text attribute editor handles the
>-editing and rendering of the <span style="font-family: monospace;">summary</span>. Attribute editors make use
>+rendering of the <span style="font-family: monospace;">startTime</span>,
>+and a text attribute editor handles the
>+editing and rendering of the <span style="font-family: monospace;">summary</span>.
>+Attribute editors make use
> of wxPython widgets to help out with the rendering and editing.<br>
>
>-
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
>-
>-We've also been experimenting with the ability to script the application, which we call <span style="font-weight: bold;">CPIA Script</span>.
>+We've also been experimenting with the ability to script the
>+application, which we call <span style="font-weight: bold;">CPIA
>+Script</span>.
> In 0.6 we've been focused on using scripting to automate functional
> tests, but we hope to extend it to allow adventurous users to customize
> their environment with scripts and potentially share scripts. Yes, we
>@@ -571,7 +371,8 @@
> <br>
>
> <span style="font-weight: bold;">
>-Key decision:</span> CPIA is not meant to be a general cross platform
>+Key decision:</span> CPIA is not meant to be a general cross
>+platform
> application building framework (ala XUL or wxWidgets). We're
> not trying to boil the ocean here. Chandler specific concepts like
> Items, Collections, Sidebar, Summary View and Detail View
>@@ -579,177 +380,100 @@
> framework. <br>
>
> <span style="font-weight: bold;">
>-
>-
>-
> </span>
> <h5>Most CPIA code can be found here:</h5>
>
>-
>-
>-
>-
> <ul>
>
>+ <li><span style="font-weight: bold;">parcels.osaf.framework.blocks</span>
>+General block and widget definitions, including base classes and the
>+SummaryTable block</li>
>
>+ <li><span style="font-weight: bold;">parcels.osaf.framework.blocks.calendar</span>
>+Calendar blocks and widgets</li>
>
>+ <li><span style="font-weight: bold;">parcels.osaf.framework.blocks.detail</span>
>+Detail view block and widget</li>
>
>+ <li><span style="font-weight: bold;">parcels.osaf.framework.attributeEditors</span>
>+Attribute editor infrastructure and attribute editors</li>
>
>- <li><span style="font-weight: bold;">
>-parcels.osaf.framework.blocks</span> General block and widget definitions, including base classes and the SummaryTable block</li>
>+ <li><span style="font-weight: bold;">parcels.osaf.framework.scripting</span>
>+Scripting framework</li>
>
>+ <li><span style="font-weight: bold;">parcels.osaf.framework.types</span>
>+CPIA defined repository types (e.g. color)</li>
>
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-parcels.osaf.framework.blocks.calendar</span> Calendar blocks and widgets</li>
>-
>-
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-parcels.osaf.framework.blocks.detail</span> Detail view block and widget</li>
>-
>-
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-parcels.osaf.framework.attributeEditors</span> Attribute editor infrastructure and attribute editors</li>
>-
>-
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-parcels.osaf.framework.scripting</span> Scripting framework</li>
>-
>-
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-parcels.osaf.framework.types</span> CPIA defined repository types (e.g. color)</li>
>-
>-
>-
>-
>-
> </ul>
>
>-
>-
>-
>-
>-
> <h3><a name="Services"></a>Services</h3>
>
>-
>-
>-
>-
> The services layer provides services to allow Chandler to talk to the
> outside world. Currently this includes sharing (via WebDAV and <a href="http://ietf.webdav.org/caldav/home.html">CalDAV</a>),
> email (via IMAP and POP), and support to run Chandler as a local
> webserver.<br>
>
>-
>-
>-
>-
>-
> <br>
>+
> The Chandler application allows users to "share" Collections by
> publishing them to a server. Similarly, Chandler can subscribe to
> Collections on a server. Chandler also supports import and export of
> calendar data. Chandler supports this functionality with a flexible
> sharing framework.<br>
>+
> <br>
>+
> <img style="width: 482px; height: 158px;" alt="sharing framework" src="SharingFramework.gif"><br>
>+
> <br>
>-The sharing framework shares a Collection by creating three objects: a <span style="font-weight: bold;">Share</span>, a <span style="font-weight: bold;">Format</span>, and a <span style="font-weight: bold;">Conduit</span>.
>-The Share object is the coordinator, making decisions about which Items
>-need to be imported or exported. The Share delegates the serialization
>-and deserialization to the Format object. Supported Formats include the
>-standard iCalendar format, as well as <morgen help!>. Moving the
>-serialized representations in and out of Chandler is delegated to the
>-Conduit object. Current implementations include a FileSystem conduit
>-(supporting import/export), as well as WebDAV and CalDAV. More
>-information about sharing, including the 0.6 spec, can be found <a href="http://wiki.osafoundation.org/bin/view/Projects/SharingProject">here</a>.
>+
>+The sharing framework shares a Collection by creating three objects: a <span style="font-weight: bold;">Share</span>, a <span style="font-weight: bold;">Format</span>, and a <span style="font-weight: bold;">Conduit</span>. The Share
>+object is the coordinator, making decisions about which Items need to
>+be imported or exported. The Share delegates the serialization and
>+deserialization to the Format object. Supported Formats include the
>+standard iCalendar format, as well as <morgen help!>.
>+Moving the serialized representations in and out of Chandler is
>+delegated to the Conduit object. Current implementations include a
>+FileSystem conduit (supporting import/export), as well as WebDAV and
>+CalDAV. More information about sharing, including the 0.6 spec, can be
>+found <a href="http://wiki.osafoundation.org/bin/view/Projects/SharingProject">here</a>.
> The sharing framework can be extended to add new conduits and formats,
>-a tutorial on how to extend sharing can be found here. <insert link
>-to morgen's doc><br>
>+a tutorial on how to extend sharing can be found here. <insert
>+link to morgen's doc><br>
>+
> <br>
>+
> Chandler's sharing code makes use of a library called <a href="http://wiki.osafoundation.org/bin/view/Projects/ZanshinProject">Zanshin</a>,
> which supports collaboration over HTTP, WebDAV and CalDAV. Zanshin is
> an OSAF project with no dependencies on the rest of Chandler.<br>
>+
> <br>
>
>+Zanshin and Chandler use the <a href="http://twistedmatrix.com/">Twisted</a>
>+framework for networking support. Chandler
>+services like mail and sharing run in the Twisted Reactor. See <a href="overview.html#Threading_Model">ThreadingModel</a>
>+below for more information on how this works. More information on
>+Twisted in Chandler can be found <a href="http://wiki.osafoundation.org/bin/view/Projects/TwistedHome">here</a>
>+and here. <insert link to startup document><br>
>
>-
>-
>-
>-Zanshin and Chandler use the <a href="http://twistedmatrix.com/">Twisted</a> framework for networking support. Chandler
>-services like mail and sharing run in the Twisted Reactor. See <a href="overview.html#Threading_Model">ThreadingModel</a> below for more information on how this works. More information on Twisted in Chandler can be found <a href="http://wiki.osafoundation.org/bin/view/Projects/TwistedHome">here</a> and here. <insert link to startup document><br>
>-
>-
>-
>-
>-
> <h5>
> Most services code can be found here:</h5>
>
>-
>-
>-
>-
> <ul style="font-weight: bold;">
>
>+ <li>parcels.osaf.sharing <span style="font-weight: normal;">Sharing
>+services, including CalDAV and WebDAV sharing</span></li>
>
>+ <li>parcels.osaf.mail <span style="font-weight: normal;">Mail
>+services, including IMAP and POP</span></li>
>
>+ <li>parcels.osaf.webserver <span style="font-weight: normal;">Code to run Chandler as
>+a webserver </span></li>
>
>-
>- <li>
>-parcels.osaf.sharing <span style="font-weight: normal;">Sharing services, including CalDAV and WebDAV sharing</span></li>
>-
>-
>-
>-
>-
>- <li>
>-parcels.osaf.mail <span style="font-weight: normal;">Mail services, including IMAP and POP</span></li>
>-
>-
>-
>-
>-
>- <li>
>-parcels.osaf.webserver <span style="font-weight: normal;">Code to run Chandler as a webserver </span></li>
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
> </ul>
>
>-
>-
>-
>-
>-
> <h3><a name="Domain_Model"></a>Domain Model</h3>
>
>-
>-
>-
>-
> The domain model layer defines all of the "problem domain" classes that
> represent application content such as Calendar Events, Mail Messages,
> Tasks, etc. It plays the role of the Model in an MVC architecture. This
>@@ -757,392 +481,215 @@
> above it, allowing it to be used equally effectively by different types
> of Views and Controllers.<br>
>
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> The domain model layer primarily consists of Python class
> definitions for these domain specific Kinds: calendar events, mail
>-messages, tasks and contacts. Each of these classes is a subclass of <span style="font-weight: bold;">ContentItem</span>. The ContentItem class is a base class for all Items that
>+messages, tasks and contacts. Each of these classes is a subclass
>+of <span style="font-weight: bold;">ContentItem</span>.
>+The ContentItem class is a base class for all Items that
> the user would typically
> think of as their personal data.<br>
>
>-
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> This layer also includes the code for Collections and for
>-notifications to the layers above. See <a href="#Collections_and_Notifications">Collections</a> for more
>+notifications to the layers above. See <a href="#Collections_and_Notifications">Collections</a>
>+for more
> information.<br>
>
>-
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
>-
> As 0.6 was a calendar release, much of the domain model work went into
> making recurrences and timezones work. You can read about this in
> more detail:<br>
>+
> <ul>
>- <li><a href="http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_6/Timezone-0.6.html">0.6 Timezone specification</a></li>
>- <li><a href="http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_6/Reccurence-0.6.html">0.6 Recurrence specification</a></li>
>-</ul>
>
>+ <li><a href="http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_6/Timezone-0.6.html">0.6
>+Timezone specification</a></li>
>
>+ <li><a href="http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_6/Reccurence-0.6.html">0.6
>+Recurrence specification</a></li>
>
>+</ul>
>
>-
>-
> <span style="font-weight: bold;">
>-
>-
>-
>-
>-
>-Terminology note</span>: We've have called this layer the "content model" in the past, so
>+Terminology note</span>: We've have called this layer the
>+"content model" in the past, so
> you'll find that term in the code. I chose "Domain Model" for this
> document because that term is more consistently used for this type of
> layer in other projects. We're still wrestling with the terminology and
> hope to clarify this further in 0.7.<br>
>
>-
>-
>-
>-
> <h5>
> Most domain model code can be found here:</h5>
>
>-
>-
>-
>-
> <ul>
>
>-
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-parcels.osaf.pim</span> Defines
>+ <li><span style="font-weight: bold;">parcels.osaf.pim</span>
>+Defines
> the obvious PIM related Kind classes (e.g. CalendarEvent, MailMessage,
> Task). Also contains more general Kind classes (e.g. Collection,
> ContentItem).</li>
>
>-
>-
>-
>-
> </ul>
>
>+<h3><a name="Parcel_Framework">Parcel Framework</a></h3>
>
>+The parcel framework layer provides basic services for parcels, from
>+access to the Repository to access to the threading services of the
>+Twisted framework. It also provides hooks for parcels to run code at
>+startup.<br>
>+<br>
>+The <span style="font-weight: bold;">schema</span> module provides an API for creating Item objects and Kind classes. Kind classes are created by subclassing <span style="font-family: monospace;">schema.Item</span>. Attributes are added to Kinds by defining <span style="font-weight: bold;">attribute descriptors</span>
>+in the Python class, which are much like Python property definitions.
>+Item objects can be created by calling the class constructors. The
>+schema module also provides an API for updating or creating well known
>+Item objects.<br>
>
>-
>-
>-
>-<h3><a name="Schema"></a>Schema</h3>
>-
>-
>-
>-
>-
>-The Schema layer provides an API for creating Items and defining
>-Python classes that implement Kinds. Most Chandler code in the layers
>-above will use this API instead of going to the repository directly.<br>
>-
>-
>-
>-
>-
> <br>
>+Parcels are both a mechanism for persisting Item objects and Kind
>+classes to the Repository at startup, as well as a packaging mechanism
>+for components in Chandler. Extensions to Chandler are packaged up as
>+Parcels, for example. We created Parcels before the existence of <a href="http://peak.telecommunity.com/DevCenter/PythonEggs">Python Eggs</a>
>+(or at least before we knew about them). In future releases we plan to
>+replace Parcels with Eggs as a unit of component packaging.<br>
>+<a href="#Parcel_Framework"><br>
>+The Parcel Developer's Guide to the Schema API</a> provides an excellent tour through the schema api, with more detailed information. <br>
>+<br>
>+The <span style="font-weight: bold;">starup</span> module provides
>+hooks for running code at application startup. It provides classes
>+that help run code in a separate thread, classes that run in the
>+Twisted reactor (<span style="font-weight: bold;">TwistedTask</span>), and classes that run at periodic intervals in the Twisted reactor (<span style="font-weight: bold;">PeriodicTask</span>). More about the <a href="#Threading_Model">threading model</a> below. More about the startup module <a href="#Parcel_Framework">here</a>.<br>
>
>-
>-
>-
>-
>-<pointer to phillip eby's document (or consider
>-lifting parts of that doc if they are appropriate here)><br>
>-
>-
>-
>-
>-
> <h5>
> Schema layer code can be found here:</h5>
>
>-
>-
>-
>-
> <ul>
>
>+ <li><span style="font-weight: bold;">application.schema</span> API for defining Chandler parcels and schemas</li>
>+ <li><span style="font-weight: bold;">application.Parcel</span> Controller code that loads parcels into the Repository.<span style="font-weight: bold;"><br>
>+ </span></li>
>
>+ <li><span style="font-weight: bold;">parcels.osaf.startup </span>Hooks for running code at startup, including TwistedTask and PeriodicTask<span style="font-weight: bold;"><br>
>
>-
>-
>- <li><span style="font-weight: bold;">
>-application.schema</span></li>
>- <li><span style="font-weight: bold;">parcels.osaf.startup<br>
> </span></li>
>- <li><span style="font-weight: bold;">
>-parcels.osaf.framework.twisted</span> <span style="font-weight: normal;">Chandler specific utilities wrapping twisted services</span></li>
>
>+ <li><span style="font-weight: bold;">parcels.osaf.framework.twisted</span>
>+ <span style="font-weight: normal;">Chandler specific
>+utilities wrapping twisted services</span></li>
>
>-
>-
>-
> </ul>
>
>-
>-
>-
>-
> <h3><a name="Repository"></a>Repository</h3>
>
>-
>-
>-
>-
> The Repository is the persistent store for Chandler's data driven
>-architecture. It implements the core code for Items and sets of Items,
>-as well as notifications.<br>
>+architecture. It implements the core code for Items and sets of Items (the basis of Collections),
>+as well as notifications. It also supports full text search, sorting and indexing of sets of Items.<br>
>
>-
>-
>-
>-
> <br>
>+The Repository is essentially a Python object cache sitting on top
>+of <a href="http://www.sleepycat.com/">BerkeleyDB</a>. It uses <a href="http://lucene.apache.org/">Lucene</a> as the full text search engine. <a href="http://pylucene.osafoundation.org/">PyLucene</a>
>+is an OSAF project to make Lucene available to Python applications. For
>+more information on the creative acrobatics used to get this to work,
>+look <a href="http://svn.osafoundation.org/pylucene/trunk/README">here</a>.<br>
>
>-
>-
>-
>-
>-You can think of the Repository as a Python object cache sitting on top of BerkeleyDB. <br>
>-
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
>-<more here: cover commit/refresh, cvs/svn like tx model, units of work potentially tied to undo><br>
>-
>-
>-
>-
>-
>+Client code gets access to the Repository through a <span style="font-weight: bold;">RepositoryView</span>
>+object, which is a connection to the Repository. Client code creates,
>+retreives and updates Items in the repository view, which has an object
>+cache local to the view. The client code can then <span style="font-weight: bold;">commit</span> the modified Items back to the core Repository, or <span style="font-weight: bold;">refresh</span>
>+changes from the core Repository back into the view. The client code
>+can also roll back changes. The transactional model is similar to that
>+of cvs or svn. No locking is required, changes are either successfully
>+merged or result in a conflict error during commit or refresh. The hope
>+is that conflicts will be rare if we write the merging code well, and
>+that the application will be able to present certain conflicts to the
>+user and let the user make decisions about how to resolve them. (We
>+have no such user interface in 0.6, we resolve conflicts at higher
>+layers without involving the user).<br>
> <br>
>+The Repository contains the core implementations for Items, Kinds, and
>+Attributes. Layers above the repository use the schema api instead of
>+using the Repsitory's API directly (with some exceptions, like the
>+RepositoryView).<br>
>
>-
>-
>-
>-
>-- BerkeleyDB<br>
>-
>-
>-
>-
>-
>-- PyLucene
> <h5>Repository layer code can be found here:</h5>
>
>-
>-
>-
>-
> <ul>
>
>-
>-
>-
>-
>- <li><span style="font-weight: bold;">
>-repository.*</span>
>+ <li><span style="font-weight: bold;">repository.*</span>
> </li>
>
>-
>-
>-
>-
> </ul>
>
>+<h2><a name="Extension_Parcels"></a>Extension
>+Parcels</h2>
>
>-
>-
>-
>-<h2><a name="Extension_Parcels"></a>Extension Parcels</h2>
>-
>-
>-
>-
>-
>-
>-Third parties can extend Chandler by writing their own parcels. Third party
>+Third parties can extend Chandler by writing their own parcels. Third
>+party
> parcels largely look very similar to Chandler core parcels --
> definitions of Item objects and Kind Python classes. Third party
> parcels can define Items and classes that belong in any
> of these top level layers:<br>
>
>-
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> <img style="width: 248px; height: 183px;" alt="parcel layers" src="overview-parcel.png"><br>
>
>-
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> The parcel can define Items that we think of as belonging to the
>-application layer: Menus, event handlers, blocks to customize a
>+application layer: Menus, event handlers, blocks to customize
>+a
> detail view, etc.<br>
>
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> The parcel can define Python classes that we think of as belonging to
> the CPIA layer: a custom summary view Block and Widget, or a custom
> AttributeEditor.<br>
>
>-
>-
>-
>-
> <br>
>
>+The parcel can define Python classes that we think of as belonging to
>+the Domain Model: new Kinds of Content Items.<br>
>
>-
>-
>-
>-The parcel can define Python classes that we think of as belonging to the Domain Model: new Kinds of Content Items.<br>
>-
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
> The parcel can define Python classes that we think of as belonging to
> the Services layer: PeriodicTasks to fetch Items into the repository.<br>
>
>-
>-
>-
>-
>-
> <br>
>
>-
>-
>-
>-
>-
> The third party parcel might separate out the code into Python modules
> based on these layers, or might include them all in one module if the
> parcel is small enough -- its up to the judement of the parcel
> developer.<br>
>
>-
>-
>-
>-
> <h5>
> Sample extension parcels can be found here:</h5>
>
>-
>-
>-
>-
> <ul style="font-weight: bold;">
>
>+ <li>parcels.flickr <span style="font-weight: normal;">Creates
>+a collection of Flickr photos in the sidebar.</span></li>
>
>+ <li>parcels.amazon <span style="font-weight: normal;">Fetches
>+an amazon wish list into the repository.</span></li>
>
>+ <li>parcels.feeds <span style="font-weight: normal;">Sample
>+RSS reader, which is documented in the <tutorial>.</span></li>
>
>+ <li>parcels.photos </li>
>
>- <li>
>-parcels.flickr <span style="font-weight: normal;">Creates a collection of Flickr photos in the sidebar.</span></li>
>-
>-
>-
>-
>-
>- <li>
>-parcels.amazon <span style="font-weight: normal;">Fetches an amazon wish list into the repository.</span></li>
>-
>-
>-
>-
>-
>- <li>
>-parcels.feeds <span style="font-weight: normal;">Sample RSS reader, which is documented in the <tutorial>.</span></li>
>-
>-
>-
>-
>-
>- <li>
>-parcels.photos </li>
>-
>-
>-
>-
>-
> </ul>
>
>+<h2><a name="Internationalization"></a>Internationalization
>+(i18n)</h2>
>
>-
>-
>-
>-
>-<h2><a name="Internationalization"></a>Internationalization (i18n)</h2>
> The 1.0 version of Chandler will contain infrastructure support for
> Internationalization (hereafter referred to as i18n). This includes the
> ability to localize the GUI strings (menus, tooltips, status, text
>@@ -1151,68 +698,56 @@
> includes locale specific support for date and time presentation,
> sorting and searching, as well as calendar and timezones. We've made
> significant progress towards this infrastructure in 0.6. <br>
>+
> <br>
>+
> One key decision was to build on <a href="http://www-306.ibm.com/software/globalization/icu/index.jsp">ICU</a>,
> an open source i18n library available in C/C++. ICU provides services
> like datetime formatting and parsing, language sensitive collation and
> searching, etc. It also contains a large set of locale data. To make
> use of ICU in Chandler, we've started a project to wrap ICU in Python,
>-called <a href="http://pyicu.osafoundation.org/">PyICU</a>. PyICU is shipped as part of the Chandler distribution.<br>
>+called <a href="http://pyicu.osafoundation.org/">PyICU</a>.
>+PyICU is shipped as part of the Chandler distribution.<br>
>+
> <br>
>+
> We're now ready to try out some test localizations; we hope to have
> localizations for French and/or Spanish in the next release. More
>-information about the i18n infrastructure can be found <a href="http://wiki.osafoundation.org/bin/view/Projects/ChandlerInternationalizationProposal">here</a>; information about helping out with localizations can be found <a href="http://wiki.osafoundation.org/bin/view/Projects/InternationalizationProject">here</a>.<br>
>+information about the i18n infrastructure can be found <a href="http://wiki.osafoundation.org/bin/view/Projects/ChandlerInternationalizationProposal">here</a>;
>+information about helping out with localizations can be found <a href="http://wiki.osafoundation.org/bin/view/Projects/InternationalizationProject">here</a>.<br>
>
> <h2><a name="Security"></a>Security</h2>
>
>+<insert short summary here m2crypto? certstore? note both
>+scripting as glaring issue as well as future signed parcels><br>
>
>-
>-<insert short summary here m2crypto? certstore? note both scripting as glaring issue as well as future signed parcels><br>
>-
>-
>-
>-
>-
>-
> parcels.osaf.framework.certstore
>-<h2><a name="Collections_and_Notifications"></a>Collections and Notifications</h2>
>+<h2><a name="Collections_and_Notifications"></a>Collections
>+and Notifications</h2>
>
>-
>-
>-
>-
>-
> <insert wise and clarifying discussion of collections and
> notifications here>
>-<h2><a name="Threading_Model"></a>Threading Model</h2>
>+<h2><a name="Threading_Model"></a>Threading
>+Model</h2>
>
>-
>-
>-
>-
>-
> <p>In Chandler, the Repository is the primary means that threads
> use to
>-communicate with each other. A thread using the Repository has its own <strong>RepositoryView</strong>, which is an independent connection to the
>+communicate with each other. A thread using the Repository has its own <strong>RepositoryView</strong>,
>+which is an independent connection to the
> Repository. </p>
>
>-
>-
>-
>-
>-<p>The UI has its own thread (wxWidgets, like all GUI frameworks, needs
>+<p>The UI has its own thread (wxWidgets, like all GUI frameworks,
>+needs
> to run in a single thread.) We're currently using the Twisted
> Reactor to schedule work that needs to happen outside the UI thread.
> The Reactor runs in a separate thread, and is used to schedule work. In
>-Chandler the units of work are called <span style="font-weight: bold;">PeriodicTasks</span>, which are Items that pesist in the Repository. Each PeriodicTask has its own <strong style="font-weight: normal;">Repository View</strong>,
>+Chandler the units of work are called <span style="font-weight: bold;">PeriodicTasks</span>, which
>+are Items that pesist in the Repository. Each PeriodicTask has its own <strong style="font-weight: normal;">Repository View</strong>,
> as does the main wxWidgets UI thread. </p>
>
>-
>-
>-
>-
> <p>To follow an example, the
>-PeriodicTask that fetches email creates new email Items in its RepositoryView. After it creates the items, it calls <strong>commit()</strong>
>+PeriodicTask that fetches email creates new email Items in its
>+RepositoryView. After it creates the items, it calls <strong>commit()</strong>
> on the RepositoryView, which pushes the Items to the Repository. The
> UI thread calls <strong>refresh()</strong>
> on its
>@@ -1220,31 +755,11 @@
> the new changes are picked up, the appropriate Widgets are dirtied so
> that they will repaint themselves in the next Paint cycle. </p>
>
>+<h2><a name="Discovery_and_Startup"></a>Discovery</h2>
>
>+<discovery paradigm not
>+registration><span style="font-weight: bold;"><br>
>
>-
>-
>-
>-
>-<h2><a name="Discovery_and_Startup"></a>Discovery and Startup</h2>
>-
>-
>-
>-<brief overview and link to pje's doc -- discovery paradigm not registration><span style="font-weight: bold;"><br>
> </span>
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
> </body>
> </html>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Commits mailing list
>Commits at osafoundation.org
>http://lists.osafoundation.org/mailman/listinfo/commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20051213/1dea55b4/attachment.htm
More information about the Dev
mailing list