06 Jul, 2009, Chris Bailey wrote in the 1st comment:
Votes: 0
I've been toying with both for telnet handling but I'm still not sure which is better. From what I've read and seen so far it seems like they both have some interesting pro's and cons. GServer is ruby standard, and well documented. It's easy to use and is of course capable of everything that EventMachine is. On the other hand, EventMachine is implemented in C and handles loads a lot better, which makes is extremely fast in comparison. It's arguable which is easier to use, what do you guys think?
06 Jul, 2009, Runter wrote in the 2nd comment:
Votes: 0
I prefer EventMachine. It's very easy to use, efficient, and I like the structure.

That being said, I don't know enough about Gserver to actually make an educated comparison.
06 Jul, 2009, Chris Bailey wrote in the 3rd comment:
Votes: 0
The two are very similar in how they present themselves to the user. The biggest Pro of GServer is that it isn't an external library, it ships with Ruby. We all know how handy it is to have as few dependencies as possible.
06 Jul, 2009, Runter wrote in the 4th comment:
Votes: 0
Chris Bailey said:
The two are very similar in how they present themselves to the user. The biggest Pro of GServer is that it isn't an external library, it ships with Ruby. We all know how handy it is to have as few dependencies as possible.


Inversely, EventMachine being implemented in C is a feature. :)
06 Jul, 2009, kiasyn wrote in the 5th comment:
Votes: 0
06 Jul, 2009, Runter wrote in the 6th comment:
Votes: 0
I've heard good things about this one too.
08 Jul, 2009, Tyche wrote in the 7th comment:
Votes: 0
The TeensyMud architecture is Schmidt's Acceptor/Connector/Reactor pattern, which was the basis of the C++ ACE framework and later Java's NIO.
The ruby code was written from a C++ mud project I was working on called the Mesh network services adapter. That software did not implement any protocol stacks.
I'm working on taking this full circle and back to a C++ network module with a complete mud protocol stack.
I'll be releasing it as part of Murk++ first, and then as a both a ruby gem and stand alone library.
08 Jul, 2009, Runter wrote in the 8th comment:
Votes: 0
Quote
and then as a both a ruby gem and stand alone library.


That would be interesting. :)
09 Jul, 2009, Chris Bailey wrote in the 9th comment:
Votes: 0
That would be awesome Tyche. I am currently trying to base a system on the Ace framework as well. When you refer to the Acceptor/Connector/Reactor pattern and Ace, do you mean the Proactor pattern? That is what I had understood the ACE framework to represent. Basically, a true asynchronous handler on architectures that support it, and an emulated asynch handler on those that don't.
09 Jul, 2009, Tyche wrote in the 10th comment:
Votes: 0
I think Proactor is more applicable to applications where the application logic can be parallelized.
0.0/10