[Dev] A block diagram for

[Mike C. Fletcher]

  So, I felt the need to draw slightly more of overview of the entire 
application (as I understand it), so I began blocking out various pieces 
of functionality in a little diagram.  Not sure how useful it will be, 
but oh well, here it is:

http://members.rogers.com/mcfletch/chandler/component_sketch.png

The basic outline is that the right hand side of the diagram can be 
loosely thought of as the data model of the application.  The central 
column is the various services used primarily by the "view" side of the 
system (and by each other).  The column on the left represents the 
graphical user interface (view) implementation.  The 
"framework/application" block is intended to represent a minimal layer 
which loads the data-model and constructs the views from the view 
definitions in the data model.

Data Model Column:

    * View Definitions -- items/objects which store view configuration
      and layout information, accessed directly by the application in
      order to create the initial environment, also accessible as
      standard items for editing (this might simply be considered a
      sub-category of item).  View definition would include such things
      as queries on the database, exceptions to standard color schemes etc.
    * Templates -- items/objects marked as "templates" for creating
      other objects (this might simply be considered a sub-category of item)
    * Items -- one of two fundamental building blocks of the data model,
      an item is an addressable object within the system.  Basically
      every "thing" in the system which is not an attribute instance is
      an item.
    * Attributes -- particular attributes of particular items, in this
      model they are considered to be separate from the items
      themselves, and from the values of the attributes (which are
      normally items). It is unclear whether the separation of the
      attribute from the item is visible to client code.
      Note that attributes definitions (properties) in this scheme have
      a somewhat wider definition than many object-oriented programmers
      might be accustomed to:
          o attribute definitions do not necessarily have particular
            classes with which they are associated
          o the definition of an attribute (a property in Python
            parlance) is itself an addressable item (first-class
            properties, as in Python)
    * RDFQuery -- this is almost a service, though without it their
      doesn't seem to be an access path to the RDF data, so I have
      included it here, it will likely be used as a service as well. I
      would guess that the implementation will be provided by whichever
      RDFStore we use
    * RDFStore, (on BTree) -- for example Redfoot/RDFLib, providing
      representation and manipulation services for RDF-formatted data,
      Daniel Krech has mentioned the soon-to-be-released BTree+ZODB
      storage mechanism for Redfoot.  My understanding is that this will
      only persist the attribute "triples"
    * Item Store -- assuming that the RDF store does not provide storage
      for the items themselves, we will need to store them ourselves.
       If we decide to use the default ZODB persistence mechanism, then
      this layer/block is basically nothing, otherwise it may be an
      abstraction mechanism.  Potentially it could even subsume the
      "attribute" storage mechanism to provide a "normal" python object
      representation for the items.
    * ZODB -- Zope's object persistence mechanism for Python, this
      consists of a number of C modules and a great deal of Python code.
       It includes:
          o object-cache mechanisms, 
          o transactional interactions, 
          o versioned storage (undo mechanisms depending on the
            capabilities of the underlying storage layer),
          o database versioning ((different than the last point) the
            ability to create a transaction-supported "personal" version
            of the database which is not committed to the main trunk (in
            CVS parlance) until explicitly committed)
          o (in version 4), a generic Interface package for Python
    * FileStorage/BerkeleyStorage/DirectoryStorage -- the ZODB plug-in
      storage mechanisms, if I'm not mistaken, the Berkeley and
      Directory versions include both undo-capable and undo-less
      implementations, while FileStorage only provides undo-capable
      storage.

View Column:

    * Active Views -- the set of currently active views (for instance,
      folder-view, inbox-view or preview-view), each active view would
      have a connection to a view definition in the database (which is
      used to create and configure the active view).  Potentially may
      include meta-views that host other views.
    * Controls -- likely furnished primarily by plug-ins, controls would
      be the base on which views would be constructed, with the idea
      being that the view mediates between the control (which might be
      quite generic) and the data model.
    * wxPython -- Python binding for the wxWindows cross platform GUI
      library
    * wxWindows -- Cross platform GUI library
    * Ghecko, Mozilla Composer -- Mozilla's HTML rendering and editing
      libraries, wrapped as wxWindows controls

Services Column:
(Here's where it gets very fuzzy very fast, I'll start at the bottom 
rather than the top since those are easier)

    * Replication and security services:
          o Jabber, an XML-based, normal Server-hosted, IM system
          o some talk about using Spread (the distribution mechanism
            which, if I am recalling correctly, is used as the structure
            for the Zope high availability server system), more of a
            middleware-like solution, messages, in-boxes, support for
            delayed and/or interrupted communications
          o will require configuration support in the database
    * File Services:
          o Backup and archiving
          o Directory watching (import of data from file system)
          o Packaging and encoding formats (e.g. zip, various unicode or
            locale-specific encodings, bin-hex, base-64 etceteras)
    * Network Services:
    * Cryptographic Services:
          o Crypto++ -- public key cryptographic services, likely to
            interact primarily with the network and format services to
            provide either encrypted channels for communication or
            signed/encrypted messages to be communicated
    * Data Format Services:
          o XML
                + RDF
                + Jabber
          o Mail
          o News
          o X-500
          o iCal/vCard
    * Profile/Preference Services:
          o Multiuser profile management
          o Storage of application, plug-in, and service (also possibly
            a plug-in) preferences
          o Likely want per-operating system adaptation layers
    * Linguistic Services:
          o Full-text Indexing Service
          o Likely Anti-spam Mechanism (Baysian filter)
          o Internationalization API
          o Spell checking
          o (possible) Thesaurus (possibly useful for automation of
            Linguistic Adapters)
          o (possible) Linguistic Adapters for AI Scanning
    * Plug-in Services:
          o Plug-in management (automated or semi-automated
            installation/upgrade/removal)
          o Plug-in registration/query
    * Event/Trigger Services:
          o Registration of events/triggers
          o Alarms and delay triggers
          o Automated/scheduled tasks
          o Change/update broadcast and subscription
    * "Artificial Intelligence" Services:
          o Input-text scanning (Agenda +)
          o Goal-driven analysis (eventually)
          o Constraint-solvers (eventually)

Anyway, hope it's useful for someone.  Enjoy,
Mike
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/