[JDEV] GLOBAL STATUS UPDATE

[Jeremie <jer@jeremie.com>]

Jabber has been making tremendous strides lately thanks to everyone here,
and the near future is going to bring this project to a whole new level of
activity and interaction as it starts to become usable as a platform.
I'll attempt to outline some of the changes that are happening and work
that needs to be done to help Jabber grow through and beyond this next
stage.

Quick outline:

--> New Jabber.org Server
--> Software/Services Available
--> Team/Project Structure
--> Web Site
--> Documentation
--> Languages (perl/java/python/tcl)
--> Jabber Architecture Updates
--> Transports
--> JNIX


=========================================
== New Jabber.org Server

Jabber.org will be moving to a new dedicated server within the next month.
Besides being faster, this new server will allow us to be more flexible in
the software we run on the server and the options we have for hosting
other projects.  I will send updates as this changeover happens.


=========================================
== Software/Services Available

 o) Additional CVS archives will be created and current tree restructured
 o) Core team members will have ssh access
 o) Anonymous FTP access to downloadables(and upload for 3rd party projs)
 o) All mailing lists moved to mailman
 o) Dedicated Jabber server for developers
 o) Mirroring system for docs/downloadables


=========================================
== Team/Project Structure

The current "project" approach used on Jabber.org isn't filling the needs,
so there will soon be "teams", "projects", and "developers".  Every "team"
will be able to oversee and manage multiple projects, such as the Jabber
Team will manage Etherx, Jabber Transport, common lib, and other pieces of
the main distribution.

Each team will be provided the following resources: cvs archive,
development list(where CVS checkin messages will be sent), announcement
list, downloadable area that's mirrored, web space, news page, and member
management resources.  The team can have one main project as well as
manage other related projects under that team.

If the project is small or hosted on a remote site, it can still be listed
as an independent project with a main developer and have access to the
mirrored downloadable area.


=========================================
== Web Site

With the new team structure, a "Web Site Team" will be formed to maintain
jabber.org.  This includes the style/navigation, graphics(adding some),
tools, and other related tasks.  To work on Jabber.org you need to
minimally have experience with HTML4 and CSS, and to work on any of the
interactive pieces you'll need to be familiar with php and mysql.  As the
traffic increases beyond the approx 5k/day, more help will be needed to
maintain it and provide a gentle introduction to Jabber.

Jabber needs a logo, a hip, groovin, happy, and yet simple logo.  What
does everyone think of hosting a logo contest?  I really don't like
choosing a logo that way, but I'm no graphics designer and hence won't be
creating a logo any time soon.  It would probably need to be a large
graphic with icon version and a companion button.

Anyone interested in participating here should watch the list for the
announcement of a "Web Site Team" in the next few weeks, or if you really
want to get started soon, email me.


=========================================
== Documentation

Similarly as above, a new "Documentation Team" will soon be formed to
maintain the bulk of the documentation work everywhere in Jabber.  Some of
the areas that need some serious work are:

+ General
 o) Introduction (gentle, easy to understand)
 o) Guide (more difficult pieces?)
 o) FAQ
+ Development Guides & FAQs
+ Jabber Architecture
+ Protocol

Beyond this, there's READMEs, man pages, code guides, site help(for the
tools available), etc...  

This may be one of the most critical pieces of Jabber to help it's
adoption, especially due to the complexity.  Concise, clear,
understandable documentation makes a tremendous difference to those
attempting to understand it, but its hard to create this documentation
without first having something to work with.

Again, anyone interested in participating here should watch the list for
the announcement of a "Documentation Team" in the next few weeks, or if
you really want to get started soon, email me.


=========================================
== Languages (perl/java/python/tcl)

Having Jabber in as many languages as possible is very important, and it
brings a whole new level of real-time messaging functionality to that
language. There are three ways every language can take advantage of
Jabber: clients, transports, and modules.  The clients and transports are
fairly straight forward, just a matter of parsing some XML and decoding
the protocol. Binding another language as a module on the server side is a
bit more challenging(similarly to mod_perl and mod_jserv for Apache) and
doesn't bring much new functionality to the language, just allows module
authors to choose another language.

Utilizing the new team concept, a team will be created for each language
base, such as a "Perl Team" and a "Java Team".  Interested developers can
become part of each team, and all projects(client, transport, module) will
be part of their team as well as a base of code utilizing those projects.

Right now I have the following four teams:
  Perl
  Java
  Python
  TCL
Please suggest any more!


=========================================
== Jabber Architecture Updates

There are two major components critical to Jabber that have not been added
yet: File Transfers and Information Querying.  Both of these will be
included in 0.7 and documentation will be posted on how they work.  Both of
them greatly increase the complexity of the system, and will be optional
for clients to implement.

With those additions, the Jabber Architecture will be conceptually
complete.  The only updates will be minor ones brought to the surface
during implementation.  Anyone building software to interact with Jabber
is safe to proceed forward with the assurance that it will not be
fundamentally changing any time soon.


=========================================
== Transports

The MOST important aspect of Jabber, and the most difficult, is
transports.  Much of the effort of the core team over the next few months
will be on transports.  Here is a small list of proposed transports:
  ICQ
  AIM
  Yahoo Pager
  IRC
  RVP/IMPP (IETF efforts)
  group (acts like a mailing list)
  game (shows users playing on a Quake/other game server)
After the first couple of transports, and with the addition of other
language bindings to build transports easily, there will likely be a large
amount of choices here... feel free to suggest more.

Currently I have a proof-of-concept ICQ and AIM transport working here at
home.  All I can say is that it is truly amazing to log in using a simple
Jabber client and see yourself show up online in ICQ and AIM, and be able
to send messages transparently everywhere.  I'll clean up the code and
post it soon, so that work can get underway on the REAL ICQ and AIM
transports.


=========================================
== JNIX

This is a secret new project that I've been harboring for some time now,
and is an extension of the previous "client lib" discussions.

The main jist of JNIX is to produce a Jabber compatible "service" for unix
systems that is transparently compatible with the old-style unix services
of talk, finger, and who.  This new service, JNIX, is aimed to be a
drop-in replacement for any unix based system, to upgrade the old-style
services with new functionality and operate on the global Jabber
network.

JNIX then can be adopted by any unix distribution, Linux or otherwise, and
that distribution will have a fully compatible(with old finger/talk)
instant messaging suite.  This is a big step for Jabber, and yet a natural
progression of finger/talk.

Soon I'll send this proposal and create the JNIX team.


=========================================

That's all for now!  It might be quiet on this list, but it's definately
busy in the background!

Thanks,

Jer