[Subversion] / PEAK / STATUS.txt  

View of /PEAK/STATUS.txt

Parent Directory | Revision Log
Revision: 1698 - (download)
Thu Feb 19 00:43:03 2004 UTC (15 years, 11 months ago) by pje
File size: 4973 byte(s)
Updated the status of peak.ddt and peak.events.  (Probably should've been
done before the a3 release, but oh well.)
High-level Package Status Information as of 2/18/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 -- basically done.  Might get some convenience features added, or maybe
 some refactoring to support any major additions.  But the core of it should
 be stable now.  More examples would be helpful.
 
 events -- basically done, with some concerns about "scheduled threads", and
 the total absence of introductory documentation.  As it's turning out,  I'm
 liking "scheduled threads" less and less, apart from their ability to fire an
 event after crashing.  At some point I may want to add a couple more event
 source types.  Mainly I'm thinking of 'Result' (akin to a Twisted 'Deferred'
 but without the chaining), and maybe a 'Forwarder' that works like a
 'Broadcaster' but has a 'forward' method on it that can be subscribed to other
 (non-conditional) 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.



cvs-admin@eby-sarna.com

Powered by ViewCVS 1.0-dev

ViewCVS and CVS Help