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.
|