[PEAK] Re: PEAK design pointers

[Paul Moore]

"Phillip J. Eby" <pje at telecommunity.com> writes:

>>But I can't work out how to connect them all together (well, I can,
>>but that's when all the nice modularity and flexibility breaks
>>down...)
>
> Well, if I understand you correctly, I'd probably write something that
> would spawn an events.Task for each of the databases to be monitored,
> and create another Task that accepted the results of each of the other
> tasks in order to prepare the consolidated report and mail it out.

Right - it sounds like events.Task is the place for me to look. That's
excellent. As I said, it's pointers to the right places to look which
I was lacking...

> But, I don't really know enough about what you're trying to even know
> if that's really appropriate, or if something else would be better.

That's not surprising, I was a little short on detail in my
descriptions. Now that I have the starter, I'll play around a bit
myself, and if I have any specific questions, I'll ask again.

> The other thing I imagine I'd do is tie the components together with
> ZConfig, creating a top-level schema with sections to describe the
> individual databases, etc.  Then, my app would literally be assembled
> by a config document, like this:

[...]

> All of the DB things would get put into a list attribute on the
> application-level object, and the repository would be put in the
> repository attribute, etc.  The class that DB sections mapped to would
> have a binding to automatically start their data collection task, and
> of course you could have lots of other configuration settings on them.

Interesting. I have looked at ZConfig in the past, but found it hard
to get to grips with. Maybe it was the bit about writing schemas in
XML that put me off :-)

In my case, the list of monitored databases (all of which are Oracle
databases which I connect to with cx_Oracle, BTW) is held in the
repository, so there's less configuration data than you are assuming.
But I take your point.

One other point, which I've never found a really good configuration
answer for, is that I have a number of SQL queries I may want to
execute (based on application line options, and the like). I can store
these in separate files, and have configuration items

[queries]
performance = config.fileNearModule("monitor", "perf.sql")
space = config.fileNearModule("monitor", "space.sql")

and so on. (Or the ZConfig equivalent...)

But the SQL is usually quite short, and I wonder whether putting it
"inline" would be better. What do you think?

>>But as I say, my question is less about the specifics of my
>>application, and more about how to *think* about this sort of design.
>
> If you're thinking about the kind of problems I think you're thinking
> about, this is probably the way to go.  That is, design in terms of
> pluggable components, and let ZConfig do the selection, configuration,
> and assembly of those components for you.

Thanks. You've given me plenty to think about, and research.

Paul
-- 
This signature intentionally left blank