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.
Powered by ViewCVS 1.0-dev