[JDEV] FW: jabberbeans

[Patrick McCuller]

> I was about to ask the very same questions!  first thing I tried was
> moving the com.java.swing stuff over
> to javax.swing and then I realized that the Channel/
> Pipeline code wasn't functional so it was almost all
> for naught.

	I'm designing additions to the Channel class to support sending/receiving
packets. Expect code very soon.

>
> In addition to beanifying the Channel for low-level
> communications, how about making some UI beans for
> things like a Roster and a User object.  That will
> make it easier for GUI builders to drop Jabber connections into
> existing apps.

	That's a great idea, but I suggest building a new library on top of
JabberBeans to do it. JabberBeans was originally intended to be a low-level
Jabber-transport API, which it will do very well I'm sure. After looking at
the Swing/GUI component, I'm fairly convinced it is only there for testing
purposes. It is the only place where Swing is used, for example. I fooled
around with it for an hour or so too, then discarded it and wrote my own. I
think there's something to gain by keeping Swing - and all GUI components -
one layer above the JabberBeans.


>
> Another thing that may or may not be worthwhile is
> replacing the homegrown xml parser with the free (feeless, that is) one
> from javasoft.  It's bulkier definately, but it's got more features.  I
> think
> most of the necessary changes would be localized to
> ProtocolBuilder.   Are there DTDs for anything in
> the Jabber protocol?

	Check the JDEV mailing list archive, there are a couple DTDs in there. As
for the homegrown XML parser, I agree that we should substitute something
more substantial. How about IBM's XML4J instead, though?

>
> -Sean McCullough


Patrick McCuller