RE: [JDEV] Suggestions

["Thomas Charron" <tcharron@nermail.ups.com>]

> From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of
> dave@raystewart.com
> Subject: [JDEV] Suggestions
> 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. :)

	I'm insulted..  I think I shall now have to put on my black trench, grab my
copy of Doom, and head over to your house..

	(*JOKE!!!!*)

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

	Never heard of it..  ;-P  Seriously, though, I do have my current code
commented, but have not checked in to CVS as of yet. (And seeing how this is
the Win32 code, prob. won't do you much good, beside's, perhaps, a simpler
example of using xpt_pool..)

> 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

	'Spec with Windows code..  With all of the bloat that Visual C++ has in it,
good commenting is critical to understand what the hell is going on under
the hood.  I totally understandwhere your comming from..

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

	Sshh..  You want us to give away our secrets??  But then people could
UNDERSTAND it, and we wouldn't look NEARLY as SMART!!  (ANOTHER JOKE!..
Jer, put DOWN THAT GUN, RIGHT NOW!!)

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

	Which is why in the Windows code, I'm not using a bit of their networking
code.  Microsoft Foundation Classes has a class named, ironically enough,
CAsyncSocket, which uses callbacks to tell you when you can send/recieve.
Here's a breif desc. of how it works:

You try to send out using CAsyncSocket::Send().  If it fails, add it to an
outgoing buffer.  Also set up a timer to call CAsyncSocket::Recieve() a
couple times a second. If either fails becouse of blocking, when the socket
is free again, the functions that you override, CJabberSocket::OnSend() and
CJabberSocket::OnRecieve(), are called.  As much as I don't like Microsoft
as a company, MFC is pretty damned nice..

Also, when you call Connect(), you can go on your merry way, as OnConnect()
is called when it connects.  There are several callbacks that allow you to
thread is and work off of callbacks.

If you KNOW of any non Microsoft classes that do this as well, I'd LOVE to
get my hands on 'em.  I could then make my libs cross platform vs. tied to
Microsoft OS's..

--
Thomas Charron
United Parcel Service
Northeast Region
"Moving at the speed of a T3 Trunk Line!"