[PEAK] A taxonomy of event sources: designing the events API

[Ulrich Eck]

[snip]
> Hm.  Well that doesn't sound too bad...  five classes, maybe an abstract 
> base, and one more if you count Thread.  Not bad at all for an event-driven 
> programming microkernel!  Oh yeah, throw in the 'resume()' function, and a 
> 'threaded()' advice wrapper.
> 
> There will also be the scheduler and I/O selector components, but 
> technically they're not part of the microkernel.  You can actually use 
> event threads without any kind of scheduler or selector if you don't need 
> to wait for time or I/O events.
> 
> I also did a bit of research, looking at Twisted's half-dozen or so reactor 
> variants for supporting different GUI frameworks, and they all look like 
> variations of the idea I had the other day for simply adding a 
> periodically-scheduled event thread that asks the GUI framework for GUI 
> events, and/or using the GUI framework's I/O event support to schedule 
> I/O.  We can interoperate with Twisted's support for these by simply adding 
> a thread to 'iterate()' the Twisted reactor repeatedly, or by adding GUI 
> threads on our own.  Similarly, we can either have a raw I/O selector 
> manage I/O event sources, or we can implement an I/O selector that works by 
> delegating to a reactor.  Heck, the scheduler can also be implemented as 
> either a standalone scheduler, or as a component that schedules threads 
> using a reactor.  Either way, the interface can be the same.

yep .. i use twisted with peak and wxPython currently by calling the
Process method of a wxApp in a reactor callback which works fairly well.

> So, the parts of peak.events that will lie beneath scheduling -- 
> fundamental event source types and the event thread type -- really *are* a 
> microkernel that doesn't care much what architectures you build on top of it.
> 
> I think that about wraps this up.  Unless somebody can see some gaping 
> design flaws that I've missed here, or has some use cases that aren't 
> covered, I think this represents a decent plan for the microkernel 
> API.  Thoughts, anyone?

sounds pretty well thought. i think this concept basically covers a
broad range of needs for low-latency event/scheduling system.
We've talked about such a thing a few times and i appreciate, that this
concept makes its way into peak in such a nice way.

I'll be on holiday for a month from mid of next week and so i'm pretty
busy getting my office desk clean and other things done .. so i probably
won't have a chanche to refactor the Wiki-Pages about p.w.t/ZPT i think.

I'm really looking forward to rewrite my workflowstuff to use
peak.events .. it will fit perfectly i think :))

cheers

Ulrich


-------------------------------

Ulrich Eck
net-labs Systemhaus GmbH
CEO & Code-Artist
Ebersberger Str. 46
85570 Markt Schwaben - Germany

eMail: ueck <at> net-labs.de
phone: +49 8121 4747 10
fax:   +49 8121 4747 77