Delta XMPP Project

Cutestuff/network has some good stuff, but even so, I find myself writing a lot of the same code over and over. Qt offers a nice cross-platform network API, and cutestuff/network draws from this, but it doesn’t really take it to the next level. After looking at Python Twisted, it seems to me that maybe a similar application protocol framework would be very useful. This should be fairly easy to implement in Qt, since most of what Twisted does is already present (such as async, events, and crypto [see qca]). We just need a few base classes to do some housekeeping. Some ideas below:

(Apologies for the incomprehensibility of the items. I’ve mainly transcribed what I had in my personal to-do list, and I plan to tidy up the text as time goes on.)

• Make ServSock work with BSockets instead of OS socket ids. If the underlying socket closes before it is tended to, the object should still remain in the queue so that the app can take action if it wants to. Don’t activate the BSocket until there is a chance to return to the event loop, so that the user can connect signals. SocksServer is a good example of what should be done, but it’s not perfect.
• Give BSocket and ServSock better names.
• Get rid of ByteStream::error(int). It should have no argument, and the error should be read via a member function. This is better than that stupid enum ErrCustom crap. Also, there should be a specific connectionFailed() signal instead of piggybacking this on error(). The reason is that when trying to share these functions among different kinds of bytestreams, it gets annoying.
• BSocket should not emit readyRead() continuously even if the underlying QSocket does. I’ve never tested this, but the QSocket docs seem to say that this “might” happen. Joy.
• Signals should never be emitted as the result of calling a function without going back to the event loop. Examples: connectToHost, setSocket. This is not a universal rule though, as I’m sure fiddling with certain widgets do cause immediate signals. What is the criteria? I hate vagueness. *sigh*
• Should objects emit many signals before returning to the event loop? Examples: connected() followed by readyRead(), or a loop of stanzaWritten() signals.
• There should be universal byte queue tracking code, possibly in BSocket, ByteStream, or someplace else, so that parent classes don’t have to do the same exact byte tracking code all day.
• What about having a “blocking” or background close() operation, so that you can close and forget about a connection even if there is stuff left to write? I see three possibilities: nothing (current behavior), background (send remaining data even if the BSocket front-end is deleted), background with blocking (same as background, but if the application tries to exit, block the shutdown until the data is written).
• Streams should have a flag (”bool isIncoming() const” ?) so that it is easy to determine if a connection is inbound or outbound.
• Maybe there should be a generic client/server base to be used for anything that does the “Client *Server::takeClient()” pattern (see SocksServer, S5B, etc). This abstraction should not necessarily be limited to just tcp sockets, but anything involving a client/server relationship (like jabber file transfer).
• Functions for pulling items out of an array, so that I don’t have to use memcpy or htons, etc.
• Generic interface to security and authentication. Protocols that use TLS, SASL, or other form of auth, could have the same members and signals (for example, dealing with certificates or prompting for authentication), such that controller or dialog code could easily be reused with other protocols.
• And of course, using security should be easy from the protocol-developer perspective as well. TLS and SASL security layers should be easy to apply to any existing stream (work on this has taken place in qca2 and also iris/xmpp-core/securestream, but there’s room for improvement).
• Getting all this solved would make me very happy. I like being happy.