powered by Jive Software

Future Plans for Smack?/Misc

Hello,

I had a look at Smack over the last days and am quite impressed - very nice code and clean api.

I am wondering about the future of Smack. What 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?

On a more technical level I would like to know if it would still be possible to introduce interfaces for classes like XMPPConnection and Roster to Smack?

I’'d like to build an eclipse plugin using Smack and 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.

I guess the late introduction of interfaces would break existing code, wouldn’'t it ;-( like Roster getRoster() -> IRoster getRoster().

I am also wondering why getRoster() is synchronous 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?

There is just one Exception available at the 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.

Just on a sidebar. Know any lightweight Jabber-server implementation which can be used for testing? I am using jabberd on debian, which installs with just one command, but for other people who have also shown interest in developing the plug-in this is not an option, as they use windoze. ?!

Cheers,

Mariano

I guess the late introduction of interfaces would

ld break existing code, wouldn’'t it ;-( like Roster

getRoster() -> IRoster getRoster().

Hmmh. I forgot about subclassing

I don’'t know the reasoning behind the architectural decisions made for Smack but I can take a stab at answering a couple of your other questions.

Jive started development of Smack to try and get the mass of Jive Forums developers excited about Jabber/XMPP to help drive the sale of url=http://www.jivesoftware.com/products/messenger/Jive Messenger[/url]. There’‘s no official Smack roadmap that I’'m aware of but you can look at the open issues url=http://www.jivesoftware.com/issues/secure/BrowseProject.jspa?id=10030here[/url].

A nice lightweight XMPP server is Jive Messenger. It’‘s extremely easy to setup and use with or without an external database. I use it a lot for testing on OSX, WinXP and Red Hat. I don’'t usually need more than 10 “users” for testing so I can use it for free.

Hi Ryang,

thanks very much. Your answers were really helpful to me.

Jabber/XMPP to help drive the sale of

Ok, great. That looks like a long term perspective to me.

There’‘s no official Smack roadmap that I’'m aware of but >you can look at the open issues

Yeah, I’‘ve seen that, but according to the issue tracker the future doesn’'t hold too many things for us

A nice lightweight XMPP server is Jive Messenger.

Brilliant. Will try that.

Cheers,

Mariano

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

However, the main reason for its existence is that we

needed a good XMPP library ourselves.

Hi Matt,

I didn’‘t mean to make my original reply sound like the sole purpose of Smack was to drive Jive product sales. I assumed you would be using Smack for inclusion in other products and meant to say so. I’'m going to blame it on my brain not yet receiving its morning dose of caffeine prior to posting.

-Ryan

Ryan,

Heh, no worries at all.

-Matt

Hi Matt,

thanks very much for taking the time to give me such a detailed answer.

using smack yourself, also selling a related product

Great! Sounds like sustained motives for lasting development

  • Support for MUC (Multi-user chat)

Brilliant. I take it, the Jive Messenger will be enhanced in this respect too, won’'t it?

loads of other enhancements

File transfer would be nice

I assume this would be for unit testing with mock

objects?

Yes.

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 am now using the Jive-Messenger which works like a charm. Haven’‘t figured out how to start it programmatically from inside eclipse, but haven’'t really tried yet.

Smack is Open Source, and we definitely welcome your

help writing test cases.

Sure thing Not sure if providing the test infrastructure should be the first thing to contribute.

Currently I am focused on getting a first cut of the plug-in to work. After that I’'d be happy to contribute minor enhancements, like making the RosterChangeListener interface more granular. For now, smack seems to do what I need, and does that just fine and intuitive.

Yes, it would break code. The other issue I have is

that it would just make the library more complex to

use.

The client code wouldn’'t be more complicated, would it?

It says you get an IRoster and as the existing Roster class is not instantiable from client classes, this wouldn’'t make it more complicated 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.

Yes, indeed it is very easy to understand right away and I see your point.

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…

First, sorry for not mentioning it first hand. Yes, I am looking at 1.3.0.

Yes, I do have a code snippet, but not at my current location ;-(

I’'ll revisit it at a later time and will post again.

There are

specific error codes available in XMPPError that you

can code UI messages to.

Ok, thanx.

Cheers,

Mariano