<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jeff Kunce wrote:
<blockquote
 cite="mid:833f4cd71002040950q7224cc10gdc9578df7047c178@mail.gmail.com"
 type="cite">
  <pre wrap="">Actually, I'm wondering about the scope of the original question about
an event-based framework:
 - Just wanting objects to communicate with events? Something simple
like circuits is good.
 - async IO? asyncore, medusa et al are tried and true
 - A comprehensive framework with everything included (even peanut
butter and jelly)? Twisted

The scope really matters.  If you just want to send simple events
between objects in your app, you could write your own circuits-like
framework before you could even figure out how to read the
documentation for Twisted.</pre>
</blockquote>
I'm building a moderately complex automated builder based primarily on
incremental builds.&nbsp; Multiple servers, each parallel in their own
right, building multiple code branches against multiple target
machines.&nbsp; So I've got three or four distinct levels of parallelism
going on in the builds already.&nbsp; And there are several types of
checking going on, including precommit speculative testing, post commit
"continuous builds", a form of partial building used for dependency
checking, and a sort of pre-pre-commit checking, (essentially branched
recurrences of the pre-commit checker).&nbsp; The builder monitors a source
code repository building when necessary as well as taking speculative
build requests from users and building those.<br>
<br>
Most of this parallelism doesn't happen in python.&nbsp; The python pieces
of the builder coordinate the various builders, partition and aggregate
very high level parallelism, manage working directories, and alerting
mechanisms.<br>
<br>
My plan is a distributed, dynamic, asynchronous, fault tolerant
architecture based on virtual synchrony,
(<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Virtual_synchrony">http://en.wikipedia.org/wiki/Virtual_synchrony</a> - probably the spread
toolkit <a class="moz-txt-link-freetext" href="http://spread.org">http://spread.org</a>).<br>
<br>
There's also a set of status and input web pages, (javascript based on
ext-js grid widget), and my plan is to produce their data using pylons,
perhaps tg2, which pulls data out of the virtual synchrony "cloud",
probably via spread, but potentially via traditional socket calls,
maybe even jsonrpc.<br>
<br>
So the "daemon"/cloud part needs to be capable of managing distributed,
shared state, including the work queue, through spread, as well as
managing a few subtasks like builds.&nbsp; I'm not big on threads, and they
don't really help much in the virtual synchrony paradigm anyway.<br>
<br>
It's not a <i>huge</i> project, but I'm expecting it to take me at
least a few months to implement.<br>
<br>
--rich<br>
</body>
</html>