[PEAK] Trellis Release and Development Roadmap

[Phillip J. Eby]

This is the current development roadmap for the various 
Trellis-related packages now in progress:


Trellis
-------

I intend to release Trellis 0.5b1 within the next week or so.  The 
API should be stable and of at least beta quality.  Features planned, 
but not yet in SVN are:

* ``.force_recalc()`` method for implementing hub-and-spoke rules
   (see http://www.eby-sarna.com/pipermail/peak/2007-July/002750.html )

* ``todo`` and ``future`` attributes
   (see http://www.eby-sarna.com/pipermail/peak/2007-July/002752.html )

* ``task``, ``Pause``, ``Return``, ``resume()``, and ``TaskCell``
   (support for pseudothreads similar to ``peak.events.Task``)

* ``poll()`` and ``volatile()``
   (support for rules that run "in the background")

* Basic ``Set``, ``List``, and ``Dict`` data structure types, with
   cells that describe their current changes

* ``values()``, ``receivers()``, ``todos()``
   (reinstate plural forms, as I found them annoying to live without)

* ``.set_value(v)`` and ``.get_value()`` methods for cell objects
   (for convenience in setting up callbacks from other systems)

* Remove dependency on the unreleased "Contextual" package
   (we're currently only using one exception class from there, and
   the features that will require it in future will be in either the
   "TrellisIO" or "TrellisDB" packages; more details below)

* Reference manual + brief developer's guide/tutorial

I believe this is a final feature list for the main Trellis 
package.  We'll promote from beta to candidate and final as feedback 
permits.  The released package should depend only on DecoratorTools 
(574 lines), ObjectRoles (205 lines), and SymbolType (34 lines), 
making it a fairly compact system overall.  I anticipate 
peak.events.trellis ending up at around 800-1500 lines of code, plus 
the dependencies.  (The current version in SVN is 410 lines without 
the above features.)


TrellisDB
---------

This will be a separately-distributed package, importable as 
``peak.events.db``.  Services to be offered here will be the factbase 
system, including relational mapping services.  The "Contextual" 
library will be required, and PEAK-Rules will probably be used as well.

TrellisDB will be organized around "record" objects, similar to the 
EIM record system I developed for Chandler, which in turn resembles 
previous experiments along these lines in PEAK and its predecessor, 
TransWarp.  The main difference between TrellisDB record types and 
EIM record types is that EIM records can be told to add or delete 
themselves from the "current database", or to yield records like 
themselves -- a kind of "query-by-example" mechanism.  Record types 
are also like predicates in first-order logic, meaning they can be 
used with "variables" to create joins and other advanced query patterns.

Queries will be represented by Trellis-based virtual set objects, so 
that changes to the database that affect the result of a "live" query 
will generate change events, allowing live updates to UI views based 
on queries.  (This is more useful for desktop apps with single-user 
databases than for anything with a multi-user database, and there 
probably needs to be some work done on sorting out how to handle 
meaningful event generation in multi-user scenarios.)

Fact bases will need to support multiple back-ends, relational and 
otherwise, but all backends will be record-based; i.e. db.Record 
types will be the backbone of all communication.

The front-end of TrellisDB will provide support for linking 
trellis.Component objects to virtual sets of records, represented as 
attributes containing simple values, sets, lists, or 
dictionaries.  In other words, the actual O-R mapping part, where 'R' 
in this case stands for 'Record' as much as it does 'Relational' 
(since there need not be a relational back-end in use).

In addition to being a useful basis for O-R mapping in applications 
of most kinds, TrellisDB would also make an excellent basis for 
someone to create a message-routing server or tuplespace/Javaspace 
type system on, a forward-chaining "expert system", or even a 
temporal rules-based event correlation system.  I don't have much use 
for building any of those things myself, but I think it's kind of 
cool that the stuff I *do* need (for desktop apps w/live query views) 
will also be sufficient to make all those other things possible.

At this point, many specifics of TrellisDB remain to be nailed 
down.  For example, how do you connect a backend to a factbase?  What 
metadata do db.Record fields need?  EIM supports a lot of metadata, 
but the TrellisDB core probably won't care about anything but what 
the field names are, and what field combinations are primary, unique, 
or foreign keys.  Yet, systems like EIM will want additional data 
both about the record types and fields, so there will probably need 
to be some sort of extensibility, similar to peak.binding 
metadata.  This may result in features being pushed back into 
ObjectRoles or DecoratorTools.

So, given the lack of specifics, it's hard to nail down a 
first-release milestone for TrellisDB yet.  Early coding milestones 
will be to implement a basic fact base, splitters, and various kinds 
of virtual sets, followed by record types and a memory 
back-end.  This will probably also require an interim release of 
Contextual to be made, and perhaps one of PEAK-Rules as well.

Work on TrellisDB will begin once the main Trellis 0.5b1 release is out.


TrellisIO
---------

This will be a separately-distributed package, importable as 
``peak.events.io``.  Services to be offered here will ultimately 
include the Time service, signals support, IPC services including 
socket/select() stuff, and support for interfacing with Twisted.  The 
"Contextual" library will be required.

There is no set timeline as yet for when work will start or finish on 
this package, as it depends on outside factors.  (E.g. client budget decisions.)