[PEAK] Re: Proposal for another Wiki "tutorial"
Phillip J. Eby
pje at telecommunity.com
Wed Jul 14 17:43:06 EDT 2004
At 10:25 PM 7/14/04 +0100, Paul Moore wrote:
>"Phillip J. Eby" <pje at telecommunity.com> writes:
> > If you are going to develop a framework like this with PEAK, the place
> > to start is with "enduring abstractions". That is, things that will
> > always be a part of the application. Or, to put it another way, what
> > is the application's "domain"?
>I see what you're getting at here, and in many ways you are right.
>However, you are assuming a single "application", if I understand you
Not really. I only got to the point of noting, near the end, that the
emergent direction of the design is to be an application with plugins,
rather than different applications per se. One reason for that is simply
that reports can be generated one of two ways: either on a specific
scheduled basis, or on demand (e.g. via a web browser). Either approach
fits nicely into a peak.events event loop, which supports FastCGI or a
built-in web server, at the same time as it supports performing scheduled
Of course, your external constraints may push things in a different direction.
Anyway, by "application" I meant "field of endeavour", not "programme". :)
>However, I have been looking at the problem in terms of
>having *many* applications. Each application will be using the same
>repository and controller, but different testers and reporter. So on
>*this* axis, the repository and controller are the "enduring"
>abstractions, and the tester and reporter are one-off items, for the
We're just using different definitions here; in a sense I'm saying that
what you call the repository and controller *are* the application (in the
program sense this time). Reporting and reaction/response rules are
"plugins" to implement specific "applications", as are the "testers".
More information about the PEAK