LibGTcpSocket Frequently Asked Questions:
============================================================================
Check here before pestering :-)

Q.	Why doesn't LibGTcpSocket use LINC?
A.	I started writing LibGTcpSocket before I knew about LINC's
	existence. Once I found out about it, I procrastinated for a
	while before attempting to rewrite GTcp* to subclass LINC. The
	problems I've found with GTcp* using LINC are these:
		1.) LINC doesn't return errors, nor does it attempt to
		    connect to multiple IP addresses if they are returned from
		    a DNS query. Since I want to do this, I have to open the
		    connection on my own, which removes a major benefit to
		    using LINC.
		2.) LINC doesn't cache DNS returns. For less-than-intellegent
		    libc's, every connection attempt means another trip to the
		    DNS server. For what LINC is designed for, this isn't a
		    big deal, since ORBit typically won't be open for
		    TCP sockets over a dialup, where querying a DNS server
		    could take a long time. Unfortunately, basically every
		    other networked app needs to be courteous to dialup users,
		    since they need to be able to do stuff over a dialup --
		    plus, in a lot of places outside the U.S., dialup users
		    get metered rates for bandwidth usage, so caching DNS
		    returns will help out a little in this case.
		3.) LINC does not show when/how much data is being written,
		    you just fire data off over the connection and LINC
		    handles the rest. That's really great if you're doing
		    something like a daemon, because 9/10 times you don't
		    really care about things like *when* the data was
		    written, just that it was at some point. This isn't *that*
		    big a deal, it just means that any kind of progress report
		    will not accurately report how much data was actually sent,
		    just how much data was handed off to LINC.
	To be honest, I'd rather GTcpSocket used LINC, because it already is,
	fourth-hand: GTcpSocket uses GConf, which uses bonobo-activation, which
	uses ORBit2, which uses LINC. Whew. In spite of all this, I'm not sure
	that making LINC do all these things for GTcpSocket is a good thing for
	ORBit, Bonobo, & friends, since it is more overhead for every GNOME app,
	even ones that never touch the network.

Q.	So, is LibGTcpSocket a GNOME Library?
A.	Not strictly. It was intended to be used primarily by GNOME
	applications, but it does not use any libraries with "gnome" in the
	name. It depends on:
		GConf2
		ORBit
		LINC
		Glib/GThread/GObject 2.0
	and optionally:
		GnuTLS (Recommended) or OpenSSL
	So, it depends on three libraries which one would typically install
	only for GNOME 2.0 (GConf, ORBit, & LINC), but are not strictly
	"GNOME-only". You make the call :-)

Q.	Why did you write *another* networking library, aren't there, like,
	5000?
A.	I didn't like any of the ones I saw. The ones that offered
	a nice API didn't offer the ability to see the real connection
	errors, which I feel is necessary for a good UI. Plus, none of
	the ones I saw really handle proxies or SSL, nor do they plug into
	a GTK+ application well. I wrote GTcpSocket to do all those.
	     GnomeVFS has some similar capabilities in it's inet-connection
	module, and it has similar dependencies, but it is not as flexible,
	it only handles HTTP proxies, and it is not as tenacious in completing a
	connection.

Q.	Where/how do I report a bug?
A.	First, if it is a crash, make sure the crash is actually
	GTcpSocket's fault, and not the app freeing some memory GTcpSocket
	expects or overflowing a recv buffer or something (after all, this
	is C). Following that, you can report bugs to:
		James M. Cape <jcape@ignore-your.tv> (GIMPNet IRC: Jimbob)
	I will add libgtcpsocket to bugzilla after 1.0 is released, or
	enough people complain about it. :-)
