Yafumato Development Log

Yafumato 0.7 <ZEX>

I haven’t posted in a while — work, training, holidays, birthdays, and general summer fun have kept me too busy to post — so Yafumato 0.7 <ZEX>, has been available for some time now. This version adds Google Talk (via the aforementioned Smack library) and MSN Messenger (via the JML library) to the collection of supported messengers. There was nothing particularly noteworthy about the development of this release; it was simply a matter of creating additional implementations of my generic messenger interface.

I am currently testing the next release, <Strife>. When this version is released MySQL will no longer be required to run Yafumato. Single sign-on and message logging will still require the database, but you will also be able to sign in using your individual messenger credentials. This should make it easier to get Yafumato up and running since fewer software packages and configuration steps will be required. Additionally, messenger sessions will be saved across HTTP sessions. When you sign in active messenger sessions will be restored into the new HTTP session rather than simply creating new messenger sessions and signing into the messengers again. I believe that, with these changes, Yafumato will be viable as a public server; I am currently investigating hosting options.

DHTML Windowing Toolkit 0.2

I have released the JavaScript windowing code used in Yafumato as a separate library called the DHTML Windowing Toolkit (DWT).

The DHTML Windowing Toolkit is a cross-browser JavaScript/CSS library for the creation of inline DHTML windows to contain content. These windows can be opened, closed, moved, and resized much like native windows. DWT 0.2 is now available. I consider the DWT included in Yafumato 0.6 <Kidd> to be version 0.1, while the updated version included in Yafumato 0.6.1 <Kidd A> is the current, 0.2 release. DWT 0.2 provides an object model for creating windows from existing elements, but cannot create the requisite elements for you. The demo included with the distribution includes examples of both static HTML and dynamic JavaScript window elements. DWT 0.2 supports Microsoft Internet Explorer, Mozilla Firefox, Opera, and Konqueror (see release notes for browser specific notes).

I wanted to split the DWT out into a separate project because I think it is a very slick piece of code that other web developers may want to use. The DWT is based on BrainJar.com’s Bride of Windows, but has been heavily modified. In particular, I have tried to allow more freedom with the window decoration. Also, the DWT code is much more object-oriented. Prototype is used for cross-browser event handling, and optional script.aculo.us effects are integrated.

The most challenging feature to implement (a feature that isn’t even used in Yafumato!) was the ability to specify multiple north-south resize targets. I had considerable difficulty distributing the pixels evenly, especially once one resize target had reached its minimum size. Originally, if there was a remainder after dividing the number of pixels that the mouse had been moved by the number of targets, each target whose index was lower than the remainder got a remainder pixel. For example, if there were two targets and the mouse was moved by three pixels, the first target would two pixels (3 / 2 + 3 % 2) while the second target would simply get one (3 / 2). This worked fairly well, but what if the user constantly resized by only one pixel? In that case, the first target would always get a remainder pixel and the second target would never get one. So, I decided to add a Boolean value to each resize target to determine whether or not it had received a remainder pixel from the last mouse move; this way the remainder pixel would alternate between the two resize targets. Nice, but what if there were three resize targets? Only the first two resize targets would get remainder pixels in this manner; the third target would never get any pixels because one of the two above it would not have been resized after the last mouse move and thus would get the pixel. The technique that I finally settled on was to give each resize target a counter that to keep track of how many times that target had been given a remainder pixel; the resize target with the lowest number of remainder pixels would get it.

So now the remainder pixels were evenly distributed, but what if the user was shrinking a window and one resize target reached its minimum size? At first, a target that reached its minimum size continued to reduce the number of pixels distributed to the other resize targets, resulting in a discrepancy between the number of pixels the mouse had been moved and the number of pixels the window had been resized. This effect was quite annoying. Thus, I changed the code so that a resize target that had reached its minimum size was no longer given any pixels when shrinking a window. However, the decision as to whether the window was shrinking or enlarging was made based on the window size when the resize drag was started. In the event that a user shrunk the window so that a resize target was at its minimum size and then started enlarging the window, the target at minimum size would not get any more pixels until the window became larger than it was when the resize was started; at that point the target would “pop” back to original size. To solve this, I had to determine whether the window was shrinking or enlarging relative to the previous mouse move rather than the original window size, which I did by saving the size after each mouse move.

Finally, resizing from the top of the window, which requires moving the window as well as resizing the contents, was also a challenge. In the end I am quite happy with the results, even if I don’t make use of them myself!

Yafumato 0.7.1 &amp;lt;Strife&amp;gt;

Yafumato 0.7.1 <Strife> has been released. MySQL is now an optional package; you just need and to get a Yafumato server up and running. Pre-built WAR files for both Tomcat 5.0 and Tomcat 5.5 are included in the distribution.

The existing single sign-on authentication method requires the database, but now you can also sign in to messenger services individually using your messenger credentials.

Messenger session handling has also been improved; messenger sessions are now saved across HTTP sessions. Active messenger sessions, those that have been successfully connected to the messenger service but not yet disconnected by you, will be recovered during sign in. Additionally, unstable messenger sessions can be disconnected and replaced using the new Reset Messenger link on the status page.

The next release, Aurion, will feature HTTP streaming for more responsive messaging. With my current schedule of teaching and business school applications, however, I won’t be able to begin working on the next release until at least late November.