Building an Openfire XMPP External Component - use Tinder or Whack? - xmpp

I'm trying to build an external component for the Openfire XMPP server, but I'm a bit confused between Tinder and Whack. Tinder seems to be the newer library and has the AbstractComponent interface which Ignite Realtime are recommending over the standard Component, however, whenever anyone talks about building an external component, they seem to be using the Whack library.
Should I be using Tinder or Whack? Or a bit of both?
Many thanks

Tinder utilises the Whack library and wraps the component in an abstract component interface so you don't have to implement all the methods for handling all types of packets if you don't need to.
Have a look at the source for the weather example.
It's also worth looking at the whack source to see how it handles the packets as this is what is ultimately connecting to your server and sending packets.
Personally I use the externalcomponent manager from whack and setup an abstract component using tinder which is exactly what the weatherabstract example does.
That's the best place to start.

Related

How to implement XMPP communication in Nativescript?

Is there any limitation in using a library like stanza.io for communication with an XMPP server like MongooseIM in Nativescript? What other alternatives are there?
If stanza.io supports NativeScript then there should not be any limitations.
On their GitHub main pager they say it's a Modern XMPP in the browser, with a JSON API. So it's mainly for browser env and I'm not sure about NativeScript.
As an alternative way - there is a xmpp.js lib which supports NativeScript. Their doc is a little bit shitty, but using src code there is a way to integrate successfully it.
There is a guide on how to use it for ReactNative, but you can some part from it for NativeScript, especially these part that are connected to the lib itself.
https://medium.com/#connectycube/xmpp-real-time-chat-in-react-native-8d6d5d23dd47
Also you can use some ready XMPP high level platforms for Chat, e.g. https://connectycube.com/2018/12/11/connectycube-textchat-code-sample-for-nativescript/
In this case you do not need to carte about XMPP server installation and monitoring
You will have to find a third party server or host your own one that implements XMPP protocols and connect to same using Websockets or XMPP plugin from your {N} application.
FYI, This XMPP plugin implements the same pod library explained in the MongooseIM docs, but the JavaScript apis are not fully implemented so you might have to access the native apis directly as needed.
You may also refer nativescript-xmpp-client, another exampel for XMPP implementation.

Comet with scala

I am developing one application with GWT as client and my server side code written in Java servelt and I am fetching some data from another server. that another server code is in Scala. so the question is how can i push data from another server to my main server and display that data to client using comet ( gwt-comet.jar)
Please help me.
Thanks
Comet is something that your web server must support, via continuations or some other implementation (see this as an example). Usually web frameworks (like Lift) have some wrapper around this mechanism to facilitate using it.
I'm no expert on GWT, but for what you say it seems it has a Comet library. Using it should be as simple as to implement classes following this library specifications and using a server that supports Comet.

Existing pubsubhubbub ajax proxy/bridge? (Like Google Feeds API v2 with Push)

I'm looking for a server side component, preferably java, that will allow me to subscribe to pubsubhubbub feeds through javascript. I understand that subscribers are server side applications in the standard rest/pubsubhubbub format, but Google seems to have created a ajax bridge that looks quite handy.
Unfortunately, I'm dealing with data that simply cannot leave our servers, let alone go through Google's.
Is anyone aware of a (preferably free) server side proxy for pseudo javascript pubsubhubbub subscribers?
Reference: http://code.google.com/apis/feed/push/docs/index.html#hiworld
I know for a fact that Kwwika and Pusherapp are working on this. I can intro you with these guys if you want.
If not, I believe this should be relatively easy to build with stuff like Node.JS for example. This code on Github should be a good first start. Things like this have been built with it.
We (superfeedr) are trying to get more people building similar things...
I'm looking for a server side
component, preferably java, that will
allow me to subscribe to pubsubhubbub
feeds through javascript
There is a java implementation]1 of the subscribe part available. But the hub-part hasn't yet been implemented in java which is needed to subscribe to the feed which should be private. For the javascript(jquery) part I would just use simple long-polling.
Is anyone aware of a (preferably free)
server side proxy for pseudo
javascript pubsubhubbub subscribers?
I don't think a free solution like that exists (yet). Even google's push API isn't open yet.
Unfortunately, I'm dealing with data
that simply cannot leave our servers,
let alone go through Google's.
There isn't yet an implementation of the HUB-part of the pubsubhubbub protoccol. But if it is internally I also don't think you need this kind of fan-out the hub(specification) is offering(broadcast to other servers).
I think you could just use A comet framework like Atmosphere to suspend connection and broadcast feed diff. I think this can be written quick with the Atmosphere framework(1 day you will have a working prototype).
You can see an example using a combination of Superfeedr and Kwwika within a web application that lets you subscribe to any RSS feed or track keywords within RSS feeds here:
http://superfeedr.kwwika.com
And you can get the source code in GitHub here:
http://github.com/kwwika/ASP.NET-MVC-PubSubHubbub-Subscriber/tree/Kwwika-Superfeedr-Demo

War room Message center

Looking for ideas on how to implement a kiosk style/full screen client that will display messages sent to it, in realtime or push based. Basically, think a 911 dispatch center call board. I was thinking a xmpp bot to display, and making a simple xmpp client that can only send messages to the bot.
This is for a very small emergency disaster agencies war room, and only needs to be able to display simple messages entered in from one of the computers in the building. Is XMPP a good solution for this?
An IM protocol like XMPP is an acceptable solution for this.
XMPP seems to fit the bill, it is mature and has many clients that support it so it would not be necessary to write a client, just set up a regular IM client to send to the "buddy" that is the big board.
Are you looking at the problem backwards? Describe what you want to do a little more THEN seek advice on protocols. It smells like you might be designing around a protocol rather than designing around your requirements.
This should be as simple as a single HTML page, running full screen, using Strophe.js and an XMPP account. Strophe is an easy-to-use XMPP library in Javascript.
Something like the basic.{html,js} example here should be pretty much what you want:
http://code.stanziq.com/cgit/strophe/strophejs/tree/
Sounds like a simple pubsub setup (XMPP will work for this) where the clients are all publishers and the War room is the only subscriber. This eliminates the need for rosters so it keeps the intial configuration pretty simple.
I don't know what language you prefer to use, but it would be rather simple in Smack using the pubsub API and any XMPP server you prefer that supports the pubsub extension. (You will need to build Smack from source though as that particular API is new and not in the release version yet.)

differences between smack, tinder and whack

Can anyone tell me what the differences are between smack, tinder and whack?
Are tinder and whack slim-down versions of smack? Do the 3 libraries serve different purposes?
Smack is a client library. You can use it to log into an XMPP domain and make use of the functionality it provides. Typically, Smack is used to implement a instant messaging client.
Tinder is a low-level XMPP library. It provides Java implementations of basic XMPP entities, such as Stanzas (called 'Packet' in XMPP), JIDs and Components (which typically implement part of the functionality of an XMPP server). Although in theory, Tinder could be used to implement client functionality, it currently is primarily used on the server-side. Both Whack and Openfire (an XMPP server implementation) use Tinder-defined entities. Smack does not use Tinder at all.
Whack is Java library that is used to implement external components. Whack allows a Component (as defined in Tinder) to run as a stand-alone process. Whack allows you to connect this process to an XMPP domain. This way, you can extend the functionality provided by that domain without modifying the implementation of the server software.
I suggest reading this Blog entry
Introducing Tinder, an XMPP object implementation library
Smack -> Cross-platform real-time collaboration client optimized for business and organizations
Whack -> Java XMPP component library
Tinder -> Java based XMPP library, providing an implementation for XMPP stanzas and components
Tinder builds on code from Openfire and Whack. Does not replace Smack but will most likley replace Whack, OpenFire (formerly WildFire)
If you wanna create an application:
Smack will be client side Library
Whack and/or Tinder will be Server side Library