[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 
events.  :)

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

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 mailing list