[TransWarp] State of the Onion (updates to current release plans)
Phillip J. Eby
pje at telecommunity.com
Thu Aug 7 19:28:27 EDT 2003
(Why onion? Onions have layers, PEAK has layers... Anyway, here's where
we're at, in terms of things to do, focused primarily on peak.web:)
* Authentication Service - basic, cookies, extensible LoginManager-alike
* Error templates - there aren't any in PEAK yet
* Forms - we need a form widgets framework (much easier said than done,
since we haven't defined precisely what that means, yet)
* "layout" templates ala Tiles, METAL, et al.
* i18n support - DOMlets that do translation, interpolation, and value
formatting. Some of this may interrelate with the form widget stuff.
Good to have:
* Skin Service - simple URL-based w/property defs to define layers
* Sessions - cookie and URL based session managers; need control over
whether session is created, what to do with expired sessions,
etc. URL-based sessions need to know whether browser is a spider, however,
and there needs to be a way to detect a browser that's ignoring cookies --
and maybe not sending referrer info either.
* Preference management - it may be useful for *some* widgets to be
"persistent" in the sense that they keep state using user preferences or
session info. (These should only be things that are preference-oriented,
not data that's part of a process, otherwise you can break the BACK button,
which is a strong no-no in my book.)
peak.storage is due for a significant refactoring, and the effects of that
refactoring may well spill over into peak.model:
* FacadeDM's and QueryDM's need to become virtually "invisible", taking a
backstage role to EntityDM's. EntityDM's should instead expose a query API
for these functions.
* We need/want a "tabular data source" API, that can be as uniform as
possible across DM's, tables, views, LDAP directories, and so on. This API
should include locking, transactions, and event notifications. This will
allow us to build reusable transform tools to map from low-level storage
and events to high-level objects and business rules. While you certainly
can build DM's more easily today than ever before, it's still not nearly
easy enough. A modestly capable user of a modern IDE -- or maybe even
Microsoft Access -- could possibly get the jump on somebody handcoding
DM's, at least for simpler applications.
These are the areas that seem important to me, looking forward through the
end of the 0.5 development cycle. Of course, there are also many minor
cleanup issues on my to-do list as well. I've been pushing hard to flesh
out peak.web in the 0.5a3 cycle, but I think the storage refactoring
probably deserves a separate release cycle, rather than tacking it on the
tail end of the peak.web work. So, probably 0.5a3 will debut an early
peak.web, without the larger new frameworks (like forms, preferences,
layout, and i18n) that aren't as well defined yet. We'll then do an 0.5a4
to finish the rest of peak.web and do the peak.storage refactoring.
The idea here is that 0.5a3 should be usable to create fully functional web
applications, but won't have any bells and whistles, and the storage APIs
will be subject to change. By 0.5 beta and final, there should be
reasonably solid APIs pretty much across the entire PEAK package suite, and
peak.web should be a joy to use.
If anybody sees anything I've left out that should be a part of the 0.5
plans, please chime in. I'll probably start in on updating the TODO file
(and my private, much more detailed to-do list) tomorrow.
More information about the PEAK