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

[Paul Moore]

John Landahl <john at landahl.org> writes:

> On Tuesday 13 July 2004 12:42 pm, Paul Moore wrote:
>> I'm thinking of putting another tutorial-style series of pages on the
>> Wiki. I'm not experienced in PEAK, so it's from the perspective of
>> someone who is learning as they go along.
>
> I'm interested in helping with this.  PEAK needs a few good example 
> applications that are small enough to digest easily while large enough to do 
> something useful.

That's my feeling, as well. Also, one of the things I want to focus on
is how to *design* a PEAK-based application. Start by breaking the
application into components, define the interfaces, join things
together, etc, etc.

> If you'd be willing to take a different approach, that of building a 
> functional PEAK+Twisted demo application, I could write a lot of the base 
> code to get the app off the ground.

I don't really want to get into Twisted at the moment. It's not
something I'd be using directly, so the learning effort would be a
distraction from my main interest. But when I get a bit further down
the line, let's see if something can be incorporated.

> There's a public space for PEAK-based application development at
> http://peakplace.tigris.org/ -- its CVS repository would be a
> natural place for this to go.

I've never really found tigris.org easy to navigate - for example the
peakplace front page mentions subprojects, but I can't find them!

I'm not sure peakplace is going to help for what I have in mind.

>> The application I have in mind is basically a server monitoring tool -
>> send "pings" to a set of servers and collect the results back.
>
> Were you planning on using pure Python to do pings, or calling out to 
> something like fping?

Actually, one of the nice things about a component-based approach, as
far as I can see, is that I can start with a completely dummy ping
component. The application would work with that, and plugging in a
"real" ping component becomes a relatively easy exercise for the
reader...

This also helps me as my real use case is to test Oracle databases to
see if they are running. For that, I'd use a ping component which
tried to connect via cx_Oracle. And if I get things right, the rest of
the application doesn't need to change!

> The latter would save a lot of time, since there don't seem to be
> any similarly comprehensive ping implementations for Python. After
> ping one would naturally want higher level protocols like HTTP,
> IMAP, SMTP, etc., which is where Twisted would come in. peak.events
> should be an integral part of the application from the beginning.
> ZConfig would be a good initial choice for specifying targets,
> groups, tests, test assignments, and alerts/notifications. At some
> point, maybe sometime after the new peak.storage arrives, it would
> be nice to keep a lot of this in a database, along with test/alert
> history.

You have an interesting perspective on this. I say interesting,
because it's so different from what I'm thinking of! It'll be a great
exercise to see how many of your ideas can fit within what I'm
developing - if they can, it's a great argument in favour of
decoupling and component based design...

I'll start an initial Wiki page in the next day or two. Have a look
and see what you think.

[In another email, Philip suggests developing from where the existing
introduction leaves off]

One reason I'm probably *not* going to do this, is that the runIni
based appication design was a definite initial stumbling block for me.
I had an idea, which I could express in "normal" Python, and I
couldn't see how to get there (ini file) from here (Python script).
I'd like my tutorial to address this, by leading the reader through a
process of taking a concept, and thinking about it in a component-
based manner. From there, binding is a natural progression, and can be
discussed in the context of a "standard" Python script (as the
existing documentation does). Naming and configuration then come in,
again as natural extensions, to allow replacement of components
without affecting the rest of the code.

Once you have an application which uses the naming, binding and config
components of PEAK, shifting the focus to applications written as ini
files is easy, as so much of what remains in "the application" is
boilerplate, and so using a library implementation of it isn't a big
leap.

But I may be wrong about this - I don't pretend to have fully
developed this idea myself, yet. It will be a learning exercise for me
as much as for the reader. Let's see how it goes.

Paul.
-- 
The only reason some people get lost in thought is because it's
unfamiliar territory -- Paul Fix