High-level Package Status Information as of 1/24/04

 binding -- very stable now, needs some more docs (what PEAK package doesn't?),
 might need to add some more metadata capabilities later, but really nothing
 significant is missing.

 config -- mostly stable. Plugins and iterability of configuration are still
 hotspots, and the "service area" concept isn't quite solid yet.  Likely, there
 will need to be a notion of "service categories" as well as areas, so that you
 can specify what categories of service a component uses, to ensure that
 autocreated components are homed at the nearest service area that has services
 of that category.

 ddt -- quite a bit more to do, but likely to be finished pretty quickly.  In
 addition to Row and Action bases, I'd like to create some web runners to allow
 you to run tests from a browser, e.g. via a local web server, or via
 CGI/FastCGI in a remote server

 events -- Still some refactoring to go, mostly in the area of conditions and
 derived event sources, but also wrt "scheduled threads".  As it's turning out,
 I'm liking "scheduled threads" less and less, apart from their ability to fire
 an event after crashing.  There's also a question of allowing threads' last
 yielded result to be offered as an event source, such that threads themselves
 become "broadcaster" event sources.

 exceptions -- I'd actually like to rename this to 'errors', or else move the
 exceptions themselves back to individual packages' 'interface' modules.
 'exceptions' actually conflicts with the name of a standard library module.

 metamodels -- this is purely an experimental thing, even though it was a
 pretty central idea for TransWarp.  It has fairly little practical value at
 present compared to its spinoff, 'peak.model', or really compared to virtually
 anything else in PEAK!

 model -- will probably suffer a major upheaval again, due to the coming
 collision of 'peak.events' and 'peak.query' with this space.  Look for model
 objects to become behavioral shells over 'events.Value' objects that hold the
 actual data, tied to 'peak.query' relvars.  Business rules, temporal rules,
 constraint validation, and GUI programming should be well-integrated or at
 least integratable. (Imagine a DM launching microthreads that monitor the
 integrity of business objects as they're modified by the UI...)

 naming -- mostly stable. It's hard to think of anything I'd change
 significantly in its current functioning, although there are definitely some
 areas for future expansion as far as writable and searchable contexts and
 serialization.

 net -- this is practically empty, but a big growth area in the coming year, as
 we will likely be adding socket services, SMTP, HTTP, Spread, and other
 goodies, building on the back of peak.events.

 query -- also near empty, also a big growth area. We need to integrate what's
 already there with cursors, with a better mechanism for managing column data
 types, and develop an API for managing writes while integrating with
 'peak.events'. (So that e.g. we can have tools that scan external data sources
 and issue events when new data becomes available, things change, etc.)

 running -- lots of junk in here, although 'commands' is really quite good, and
 'logs' is getting there.  It still seems to me that lockfiles need to
 integrate with events somehow, though I'm not yet sure how. I kind of wonder
 if we wouldn't be better off disbanding this package, moving commands and logs
 to the top level, and migrating much of the rest to 'peak.events' and
 'peak.naming.factories'.  Of particular note is the fact that although there's
 a 'peak.running.api', all it contains is a link to 'commands' for backward
 compatibility!

 security - seems quite solid, but it hasn't seen a lot of use yet, so it's
 really hard to say for certain.

 storage - big growth area, but mostly stable at the center. Likely areas of
 change include cursor metadata and how DM's work and are used.  Both are
 likely to be impacted significantly by 'peak.events' and 'peak.query', to
 support business rules and other observers as well as conceptual queries and
 declarative data transformations.

 tools -- each tool is a package unto itself, with different goals and rates of
 change; not much can be said here.

 util -- another container package with a bunch of stuff in it.  'fmtparse' and
 'readline_stack' are "cruisin' for a bruisin'", which is to say they might get
 major overhauls done or be replaced with something else.  'signature' and
 'dispatch' are likely growth areas, but perhaps not in 2004.

 web -- this is seriously incomplete. You *could* create applications with it,
 but there are lots of areas where you'll have to "roll your own" versions of
 services that really ought to be bundled. How soon this changes depends a lot
 on when/whether we end up needing it for any at-work projects.