I am wondering about the future of Smack. What is
is the rationale behind smack? Why does a commercial
company back this development? Is there some kind of
a road map detailing some of the ideas to be
implemented in the future?
To add to Ryan’‘s post – yes, one rationale for Smack is to get people interested in our commercial products. However, the main reason for its existence is that we needed a good XMPP library ourselves. We use Smack extensively in our upcoming Jive Live Assistant product. By having the library be Open Source, it’‘s better quality (more people testing it) and more fully featured (community members improving the code and making suggestions). It just makes a lot of sense for us, which is also good for everyone else since we’‘ll continue to contribute to the library’'s development.
Gato and I haven’‘t had a chance to plan out an official roadmap. There are several things we’'re planning, however:
-
Support for MUC (Multi-user chat)
-
Support for in-band-bytestreams.
-
Smack 2.0 will use “XMPP” instead of “Jabber”. Mainly, we just need to wait for server support to catch up.
-
I want to switch the PacketListener/PacketCollector architecture so that all of them are centrally referenced using weak references. This will allow us to add code to automatically cancel them when they are garbage collected (basically, cleaning up after somone if they forget to cancel a collector or unregister a listener).
-
Further refinements to the Chat object so that it’'s easier to listener for “incoming chats”.
On a more technical level I would like to know if
if it would still be possible to introduce interfaces
for classes like XMPPConnection and Roster to Smack?
I assume this would be for unit testing with mock objects? I actually think the server backend is straightforward enough that all test cases could be written with live objects rather than mock objects. That’'s how most of the test cases work at the moment, although there do indeed to be many more.
I’'d like to build an eclipse plugin using Smack and
nd I very much bought into the idea of unit testing
and test first. I am not sure though, how that would
be accomplished with Smack. The testcases coming with
the distribution seem to test corner classes only.
Smack is Open Source, and we definitely welcome your help writing test cases.
I guess the late introduction of interfaces would
ld break existing code, wouldn’'t it ;-( like Roster
getRoster() → IRoster getRoster().
Yes, it would break code. The other issue I have is that it would just make the library more complex to use. A central goal of Smack is to be as easy to use as possible. We’'re already using factories in several places but it would be nice to not have to use them everywhere.
I am also wondering why getRoster() is synchronous
us and why the received packets for this request
don’'t trigger a call to registered PacketListeners?!
Is this, because the roster comes along with the
login without the user beeing asking for it? Is this
something the proctocol requires?
When you send your presence to the server, it automatically sends roster information. I’‘m not sure what you’'re referring to about not triggering packet listeners – do you have a code example? Also, are you looking at Smack 1.3.0? You may not be based on the synchronized comments…
There is just one Exception available at the
he moment. Are there any plans to introduce
subclasses? For example, if you would try to register
a new user with a name which is already taken, it
would be nice to get UserNameUnavailableException or
similar instead of an XMPP Exception. The
XMPPException.getMessage() can also be shown to the
user, but it prevents me from providing a custom
dialog.
Yes, this area may need to be improved. I think most of this work will happen for Smack 2.0 when we move to official XMPP. The error handling in XMPP is much better defined than in the older Jabber protocol. One thing you can do for now, though, is check if the XMPPException contains an XMPPError. There are specific error codes available in XMPPError that you can code UI messages to.
Regards,
Matt