One of the original things that had me very seriously think about my choice of language for GTADS was portability and micromanagement of code. Java, in my own opinion, is a very good language for getting things done without much of the memory management overhead, especially for this project. I did however have a problem with Sun's support (or lack of) for alternative operating systems such as FreeBSD and OpenBSD (a personal favorite of mine). Getting Java working on a FreeBSD system, for example, is a very tedious task of getting components from various websites and compiling. This kills the very point of distribution of GTADS's chatserver on excellent OSs. Fortunately I had the pleasure of checking out GCJ (GCC's Java compiler) again and realizing that it would be an adequate solution for distribute the server with minor modification. Also since the server utilizes none of the GUI classes there would be no issue with compilation with GCJ, which as far as I know has no swing support. As soon as the beta release of the server is ready there will be binaries available for FreeBSD, OpenBSD, and even Linux, though it already has well a established JRE. The client however, being of a GUI interface, will still remain a JVM deployable jar, unless anyone can get it to work with GCJ in some fashion.
Moving on, development is moving, however slowly for the project. Friends List
are being implemented on the server side and will be functional by tonight or tomorrow. Friends Lists will allow users to keep track of their friends on GTADS much like how AIM or MSN work. Since I had never worked on a chatserver type project before, much of this stuff is new to me. I wanted to create a way for Friends Lists to be deployed without too much taxing of server or bandwidth resources. If you're interested to know how it works you can read on :-). A Friends List manager exist on the server passively waiting for a user to announce their state as online, offline, or away.
When a user signs on, for example, it notifies the manager that their are online and that manager propagates this state to all Friends Lists that have this user on their list. This action triggers the server to send an update to those users on the clientside to adjust their Friends List accordingly. This is a much more efficient way of doing things rather than have the Friends List purely a clientside creation that queries the server every X
seconds on the state of a friend. Creating the Friends List on the server also guarantees that whereever an account is connecting from their list will also be with them, as it will be stores locally on disk (Eventually optionally to a SQL database). A server update and a client release will complement these changes very soon and users will be able to help test this feature. Screenshots will also be up shortly showing the Friends List in action.