[jdev] The State of Our Code-bases
Nolan Eakins
sneakin at semanticgap.com
Sat Aug 28 11:12:32 CDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Yesterday I was busy hacking away at Psi implementing MUC support. One of
the things I was working on was arranging occupants by their role in the
room. One of the tests I needed to do was change an occupant's role to make
sure that the list item got placed under the correct role. Since I haven't
got to the functionality of doing that within Psi, I decided to paste in
and change one of the examples from JEP-0045 into my XML console.
To my surprise I ran into a limitation of mu-conference 0.6.0. It lacks
support for changing roles! When I sent an <iq/> based off of JEP-0045's
example 104, I got an <iq/> back with its type set to "error". I tried some
other examples and got the same thing. I figured mu-conference would
support most of JEP-0045. I guess not.
But that begs another question: do we need more server or component
implementations to replace the ones we already have?
In the case of servers, jabberd is the closest to being the "official"
Jabber server. Both versions, 1.4 and 2.0, could use some work. 1.4 needs
to be updated to XMPP 1.0 while 2.0 is far from stable. One thing is common
with both though--they work, minus some bugs here and there.
On the component front: I hit a snag with mu-conference yesterday. If you're
running jabberd and you want MUC, you run mu-conference. The problem is
that it doesn't support all of JEP-0045, making it a horrible platform to
test against. There are also an assortment of dead components too, such as
aim-t that people want to use.
With all of these pieces laying around half complete, why aren't we picking
them up and giving them a nice and polished finish? It would be a waste to
throw away all that good code, and put our effort into one more
implementation that may or may not get finished. We need to realize our
vision with the building blocks that we already have--if anything to save
time so our vision can be realized that much sooner.
All we need is ONE solid, compliant server and solid, compliant components
to complement it. By solid I mean stable, bug free, and completely there
with no surprises. If it were a physical object, you could shake it and not
hear anything bouncing around in side. By compliant, I mean that it follows
XMPP-Core, XMPP-IM, and any JEPs to a 'T'.
We don't need more. We just need the Jabber equivalent of Apache. That
should be the goal.
- - Nolan
- --
http://www.semanticgap.com/people/sneakin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFBMK71huPszQVSPEARAkY4AJ9JCFjzdvyKbOk/HsojEDZzKfzOogCbBCe5
ZHpwnMREoYSi5Ip1gtJ144I=
=mc85
-----END PGP SIGNATURE-----
More information about the JDev
mailing list