[JDEV] Krufty Jabber Client

[Scott Robinson]

I've been rolling around the ideas dreamed up for the featureful yet
portable Jabber client. (codename: Kruft?) This is my current "Feature" list
for what I hope to put into action soon.

MIME (with basic plugins)
Skins (Audio and Graphical)
Portable (Win32, POSIX + X, and Macintosh)
{
Arch Dep. == Net and Windowing Code
Arch Indep. == Scripting and UI
}
CTCP is _needed_!

Implementation wise, I've starting resolving things within my head. The
following is mostly a talk-as-I-go post. If they conflict, the last is the
best. ;)

For MIME what we want it a metamail-like system working. This is ala
Netscape, so it isn't "new" to anyone in the world. However, since we are
aiming for usability here I suggest having a raw "mailcap" file actually
included with the distribution. (on Win32 it would refer only to it, and on
UNIX it would check the [/etc/mailcap:~/.mailcap] beforehand) This mailcap
could be modified in Kruft's preferences screen in a FRIENDLY FASHION.
Meaning the user will _never see_ audio/mp3, but instead the description
"MP3 Audio File."

The client must be portable. There are a variety of cross-platform windowing
libraries around, and choosing one seems to be the problem. wxWindows seemed
a wonderful solution in the beginning, but I've already found a few problems
with it. The suggestion for Gtk+ was made, and is starting to become more
and more attractive. GTK+ is not only simple and very language agnostic, but
has significant software support. See below for another major reason.

Skins and skinning in general should be relatively simple. Ideally, the
skins should actually be the UI. However, we also wanted the client
controlled by a scripting language. This causes a tight link between UI,
scripting, and portability. It turns out the Mozilla project offers an easy
solution for Kruft. NPLayout/Gecko is available under a GTK+ port. What this
means for Kruft is we can have the entire UI spec and scripting language
under one door. Javascript and HTML! Maybe somehow through SWIG (I've looked
at it, but not enough to find out if it can do the "backwards" of what it
advertises as well...) we could have further languages attached?

While outside of Kruft itself, a CTCP should be defined. In my mind, it
would be folly not to have a set standard. You can look to IRC to see what
happens when you have hundreds of ad-hoc standards meshing together.

Comment. Please.

Scott.