Re: [JDEV] Suggestions

[Jeremie <jeremie@jabber.org>]

> 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. :) 

Thanks for taking a serious look, it's needed it badly and your
constructive criticism is welcomed and appreciated!

> To begin, let's start with a technique known as "commenting". :)

I'm the one to burn at the stake for this one, *grin*.

The dearth of comments is a problem, even for myself maintaining the code.

For some time now I've been planning on going through and commenting
everything, it just keeps getting put off and nobody has complained yet. 
But, now that someone is asking I'll make this a priority and check-in a
ton of comments this week. 

> So enough complaining, now on to the interesting stuff.

Let me add a bit of background quickly here:

I basically had to learn C to do this project.  I knew the design and
architecture of Jabber, knew what I wanted, and knew that C was the most
appropriate avenue.  The only way to get rolling was to learn C and start
coding :)

So, you may notice a ton of naive things being done in the source, and
when you do, please feel free to fix it or discuss it, it won't offend me
in any way as I know I'm doing things wrong but I don't have enough
experience(or time) to know how to do it better. 

I think the design is pretty solid, but any/all C code help is
appreciated.

> >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. 

Threads are definately the way to go on this stuff, and that's always been
in my "plan".  I knew that if I can just "make it work" and express the
intent of the design/architecture of Jabber, and others like it, they will
jump in and help me figure out threading and other issues the "right way".

> 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). 

As above, I agree 100%.  I've been trying to create a functional platform
so that others can start building clients, transports, and modules ontop
of it, and then ramp up the performance as things develop and demand it.

> 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. :) 

Yes, perfect!  If you think you have some time to seriously help out on
these parts, we can work on getting you commit access and familiarized
with the rest of the group :)

Jer