Niki Spahiev wrote:
> Hello Graham,
>
> GF> I've tried to develop a component/service approach. I separate out
> GF> database, app logic, app ui, and http services into parts, and pull them
> GF> together with a "service manager" that glues them all together at
> GF> startup time.
>
> GF> The various components are initialized and plugged into a global service
> GF> lookup namespace. So, the 'http' component can discover the 'publisher'
> GF> and 'application' components, and bind itself to them. Sequence of
> GF> initialization is important, so I specify it in the config file.
>
> GF> It's a bit young yet, but I like the approach. I've worked almost
> GF> exclusively with the Medusa publisher, but I don't see why this wouldn't
> GF> work for mod_python, scgi, etc. I'd share code if anyone wants it, with
> GF> a 'work-in-progress' caveat.
>
> This sound very much like PEAK - Python Enterprise Application Kit
>
> Niki Spahiev

I used to follow the PEAK list pretty carefully. There's a lot of great
ideas there, but Philip Eby thinks very big thoughts -- everything is
meta-something, if you know what I mean --  and it hurt my head a lot.
;-) Also, the progress to a PEAK 1.0 release seemed to be a bit slow,
which I guess is understandable for the design of such a framework, so I
kind of lost interest.

My service/component scheme was an attempt to take some basic ideas from
PEAK, RIPP and other component-oriented systems, and Get Something
Working Now. My little system has some warts that would make the Ebys
and Fultons of the world shudder, but it's good enough for a code monkey
like me.

And I find it's pleasantly complementary to Quixote; since Quixote is so
lightweight, and clear in its purpose and boundaries, it makes a
wonderful component suite. (Looking forward to the new, loosely coupled
Publisher in the 1.0 release...)

Best wishes,

-- Graham