[PEAK] Re: Proposal for another Wiki "tutorial"

[John Landahl]

On Wednesday 14 July 2004 01:59 pm, Phillip J. Eby wrote:
> A few design comments...  hope you don't mind.
>
> 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"?
...

Your ability to separate a problem into clear and distinct abstractions never 
ceases to amaze and impress.  :)

> Now, it may be that I have just designed something more like John Landahl
> wants than what you want.

It's very much what I had in mind.  I think I'll start working on some code to 
test out some of the ideas, and will check it into peakplace when there's 
something worth mentioning.

I'm thinking of using an events.Task for each test runner (e.g. test HTTP 
connectivity for system abc.xyz.com every 2 minutes), which would allow 
peak.events to do all the scheduling.  For ICMP pings it might make sense to 
have each ping request go into a queue so they can be processed periodically 
en mass through an external call to fping.

[Actually, it occurred to me that the perfect language/platform for this tool 
would be Erlang/OTP, for a number of reasons: 1) intrisic, highly efficient 
concurrency; 2) its hierarchical process supervision model can be used to 
ensure that tests are always running correctly; 3) built-in distributed 
programming support makes it simple to add multiple monitoring servers for 
load distribution and redundancy; 4) its built-in OODBMS-like database would 
be a good fit, and requires no ORM layer (downside: no SQL access to data); 
5) high uptime and fault tolerance capabilities (e.g. can update application 
code without restarting it, built-in support for application 
failover/migration).  This would be a fun project, too, and it would be quite 
interesting to see both implementations.]