From my reading, it is my understanding that server "components" can be "plugged in" to a jabber server three different ways: as a shared object library (loaded), as a separate process communicating locally over STDIO, and as a separate process communicating locally or remotely over TCP. IIRC, a process component that communicates with the jabber server over TCP is more correctly referred to as a "service." Finally, a "service," from the perspective of the jabber server, is simply a client, and as such, a service enjoys the full "presence" services of the Jabber Session Manager (JSM), whereas the "loaded" and STDIO jabber components are not handled by the JSM.
My first question is, is my above understanding accurate? Second, which modes of connecting to the jabber server as a component does the Smack API support today? If Smack does not support all of the above described modes today, which modes does Smack plan to support in the future? Thanks.
I assume you''re referring to either jabberd or the server from Jabber Inc.? I''m not very familiar with those servers since we''re more focused on our own XMPP server, Jive Messenger. However, my guess is that the only option for Smack and jabberd would be as a process componnent over TCP. You could use this for doing things like building chatbots.
In a future release, our own server will have a plugin architecture that is exposed to end users. This will allow the "shared library" type approach.
Is there any problem with using Smack as a server component over tcp/ip? I know jabberbeans is suitable for such use, and I can''t see why jabberbeans would be suitable and smack wouldn''t be. I''m currently using Marbles as a server component but I''m thinking of switching.
No, I can''t think of any reason that it wouldn''t work as a server component. However, if you describe what you''re looking to do, I can probably give a more specific answer.
I had a similar question. I want to use smack as the api to provide authentication via a server-side component. The question I had was since the connection for a component was slightly different then a regular client, I wasn''t sure if smack could support it.
Does smack support writing server-side components? And if so, does the login technique change at all? (I know the xml is different, requiring the jabber:component:accept namespace.) Any info you can probide on this?
Assuming that the authentication component you would like to write is an xdb handler for jabberd, I think that you are out of luck -- I was
The XMPPConnection class doesn''t have a method to support authenticating with jabberd as one of their accept components. login() does a lot of work that is great for actually logging in a user session, but the component API expects things to go differently.
One could certainly add a method for component authentication. I ended up using the CPAN Perl module Net::Jabber for that particular piece of my pie.
Yeah, that''s what it looks like to me too. However, it seems like it wouldn''t be too hard to extend XMPPConnection to add a login for the component login... I just have to get the SHA hashing done correctly. (Of course, if I did go down this path, I''d release the changes back to jive folks)
I wanted to keep the component in Java... and was going to check out JSO. If I''m going to leave Java, I might as well do it in C and try to keep it inprocess of the jabberd server at this rate.
Ya, it''s a tough call. We created Smack as a client library solution so there is no component oriented functionality included. You''d have to roll your own. Although, as you also mention, it is really just sign-on which should be relatively easy to add.
If you do add it we''d love to take a look and perhaps add it as a Smack extension in the standard distribution.