[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [JDEV] FW: jabberbeans
> 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