[JDEV] Suggestions

[Nicholas M. Kirsch]

Right you are, on many points. The jabberbox router will be multi-threaded
as soon as I have the time. As far as async vs. sync, that is an issue we
will have to examine. 

Nick

On Sun, 25 Apr 1999 dave at raystewart.com wrote:

> Greetings... 
> 
> I got the jabber source from CVS and have started my examination of it 
> so that I could begin design on a client library. However, I've found
> some other interesting topics that I believe we should probably
> address first. It's primarily design issues, and I'm trying to give
> constructive criticism. :) 
> 
> A disclaimer, this is *not* a flame. Please read responsibly. :)
> 
> To begin, let's start with a technique known as "commenting". :) I
> code, so I know how much of a pain it is to put comments in while
> you're hacking. However, in a project of this size, it is absolutely
> *critical* that each person submit commented code. Now, before you get 
> too steamed, let me laud you on the amount of design documents and
> discussion. Great job! Be aware, though, that in order for the code to 
> be maintainable, people must understand the interactions. For example, 
> I have found little->no information on any of the lib/ functions or
> types. What's an xpt_pool? What's it used for? What's a jpair? You
> follow? 
> 
> So enough complaining, now on to the interesting stuff.
> 
> >From what I've read of the lib/ functions, it looks like you're using
> async sockets, with polling, to handle multiple connections. Is there
> a performance advantage to using this over threads & sync sockets? I'm 
> not all that knowledgeble on async sockets, but I *do* know that
> polling is Bad News (tm). Furthermore, it tends to make the code more
> complicated, since each connection must be examined -- even if it's
> not busy. 
> 
> Let's consider the jabberbox router for a moment. As I understand the
> code (in my limited knowledge), the router maintains a list of
> connections to transports and polls these looking for inputs. As the
> routing packets come through, it parses the packet and forwards it on
> to the appropriate transport. Basically, this is a producer/consumer
> problem -- well suited to a multi-threaded approach with
> semaphores. Utilizing such an approach would probably signficantly
> (%25-%100) improve the performance of the router (especially on a
> multi-processor system). 
> 
> Well I must go now, but I'd like to hear your feedback before I
> continue. Maybe I'm wrong (it's happened before!), but I'd love to see 
> Jabber take off. I believe it's the Right Concept. All we gotta do now 
> is execute properly. :) 
> 
> D.
>