powered by Jive Software

Transport for Custom Chat protocol?

Hi.

I’m trying to bridge a legacy in-house chat protocol into the OpenFire server. But I’m not sure if it the Spark client needs any special work/code to make it support the new transport if I were to add it as an additional transport in the Gateway plugin. Since I saw this changelog for Spark 2.5.8 that there’s added support for gadugadu, irc, and also the support is now built into Spark rather than being a plugin.

Any ideas ?

P.S : Or is there a more efficient way to bridge a legacy protocol into the XMPP network ? I only need to get IM and MUC to work. I have not seen the legacy chat protocol yet though.

Do you want to use Spark? I think other clients wount need additional modification, because they have Service Browsers unlike Spark.

wroot : The only other client i know that is kinda robust is the jabber client, which I’ve never used before.

I think I missed out the main point of my question which is to ask if it’s possible (without years of effort…) to code a transport for the gateway plugin and let it work for both “user to user” and most importantly Multi user chat (legacy chat and xmpp(openfire) clients).

Since I tried the MSN gateway, and I invited two MSN friends to conference. It does not work as both my friends did not recieve a invite or get any message. Is there another way to enable/use multi user chat ? I was using the Spark client, but I suppose the transport is translating conference concepts into MSN group chat concept…

Thanks.

john2 wrote:

wroot : The only other client i know that is kinda robust is the jabber client, which I’ve never used before.

Didnt quite undrestand that. Do you mean, that other jabber clients are nor so robust/convinient as Spark? I just wanted to say that other clients should be working with customized IM Gateway (with some custom legacy transport added) without additional coding on client side. I’m not sure is it required in Spark case, but it doesnt have normal service browser, so tranports are pushed directly to Spark’s toolbar. So maybe there is something to be done to add another legacy transport support in Spark. I assume it shouldnt be much, but Daniel (developer) can tell more about this.

I think I missed out the main point of my question which is to ask if it’s possible (without years of effort…) to code a transport for the gateway plugin and let it work for both “user to user” and most importantly Multi user chat (legacy chat and xmpp(openfire) clients).

Can you say what is this legacy network you want to add? Or is it custom and unknown? AFAIK, it is not very hard to add some transport support into the IM Gateway plugin if there is good java library already available for this transport. Like joscar for ICQ. So then Daniel is adding interface for that library. If there is no such library it would take long time to write one (and to understand that transport’s protocol).

Since I tried the MSN gateway, and I invited two MSN friends to conference. It does not work as both my friends did not recieve a invite or get any message. Is there another way to enable/use multi user chat ? I was using the Spark client, but I suppose the transport is translating conference concepts into MSN group chat concept…

group chat for MSN is not yet implemented - GATE-232

Yes, it’s a custom protocol which there exist no library. And I have no idea how the protocol works, although the team behind it will tell me the details in the near future.

Meanwhile I’m trying to do research on how to best bridge it in the OpenFire server, ignoring the client component for now. Since it’s more of a server-side thing than a client thing.

But my major concern is MUC, assuming the custom protocol has a room chat function (maybe similar to irc?) how do I go about translating them into the XMPP protocol ? Also I would be very grateful if you could point me to a starter’s guide of some sort, I’ve not been able to find any books on XMPP, and the documents for plugin development isn’t very detailed.

Thanks.

For what it’s worth, the IRC transport in the IM Gateway plugin is the only one that supports MUC. It’s hard to say whether writing something from scratch or extending the IM Gateway plugin would be the best way to go. I do have an intention to make the IM Gateway plugin “pluggable” at some point. So folk could plug there own protocols into it. But that doesn’t help you “right now”. Since I’m not really writing it right now with the intention of folk adding their own, I don’t have any documentation up to help with it. I do have a lot of javadocs in place, but you’d have to generate them and such in an easily readable format.

Honestly, the best “books” for XMPP are www.xmpp.org. Especially www.xmpp.org/extensions. There you can find XEP-0100, which is the specification for gateway interaction, which might be a good starting point!

And unfortunately, yes, Spark does have specific support for transports. Most other clients have support for simple service discovery. Now, being that I’m now the lead deveoper for Spark as well, I may adjust that some. (at least add a good service discovery browser, we’ll see) Spark doesn’t -need- the custom support though, as if you register the user with the transport using the admin interface or another client, it doesn’t use the custom registration method that makes the transport “only show up in spark”.