< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous artilce (have the same parent)
N :the next article (the next thread)
|<:the top of this thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
On Jan 24, 2006, at 9:38 AM, alenpeacock / gmail.com wrote:
> You certainly could use the asynchronous completion token pattern, but
> I think if you compared implmenting that vs. implementing it using an
> event-driven framework -- even using Schmidt's EMIS Management system
> example, you'd see that the event-driven framework is not only a lot
> less work, much less error-prone and easier to debug, but also
> higher-performance (of the three advantages, I actually consider the
> performance to be least important).
>
> I know that this type of proclamation sounds like pie-in-the-sky
> bigotry against well-established practices, but I'm not kidding: once
> you go event-driven, you never go back.
>
> If there is someone already working on a libasync equivalent in Ruby,
> I'd love to pitch in. If not, I'd love to think that I could start
> one
> up.
>
> Python's twisted is very nice, but they've implemented way up the
> stack. I'd settle for something as dead simple as a generic
> event-driven TCP/UDP programming framework.
You might want to take a look at the Myriad framework [1] written by
Zed Shaw. I'm not so sure it is fully functional because I believe it
depends upon his Ruby/Event framework that he abandoned. Perhaps
you'd want to continue his work.
[1] http://zedshaw.com/projects/myriad/index.html