[TransWarp] State of the Onion (updates to current release plans)

[Phillip J. Eby]

(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:)


Critical:

* Authentication Service - basic, cookies, extensible LoginManager-alike

* Error templates - there aren't any in PEAK yet


Very Important:

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


Beyond peak.web:

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.