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.)
Related
There is a chat project I plan to develop and currently stuck while deciding, which XMPP server and client to use.
Front-end will be implemented using Ionic 3+ framework (fixed requirement).
Main features:
private chat capability (1 on 1)
group chat capability (and ability to add users to existing chat)
online status visibility
offline message delivery (online user sends a message to offline user, and the offline user gets it after going online, etc)
full-time server-side chat history storage
I need to select:
a client library which is convenient to implement with Ionic 3+
a server which enables all the above requirements
Also, the chat messages should cross the network with at least some kind of encryption.
Currently, I have been playing with these server options:
eJabberd - most people recommend this option, but for me, a person, who is newbie at XMPP stuff, it looks like there will be quite a lot of hassle with configuration
openFire - easy to setup and use, but it uses Java VM, and some people argue, that it has problems with performance and memory management.
I also stumbled upon AstraChat - a commercial product, that looks similar to what I need - however, with fixed implementation of it's own public apps - no way to use it's code base.
As of front-end - I have only tried running the Ionic 1 tutorial locally using Strophe.js as the client in the front-end. Since I am developing the app with Ionic 3+ (TypeSript), it would be awesome to use some newer and TS compatible library - however, it is just a wish, not a requirement. :)
Maybe there are some better and more convenient non-XMPP implementations for this concept. Any thoughts are welcome!
eJabbered is very complex decision for your application.
openFire is also very complex and requires JVM
For your apllication I advise Prosody. It is simple and lightweight desicion.
https://en.wikipedia.org/wiki/Comparison_of_XMPP_server_software
But please think twice about using chat on XMPP protocol. This protocol is very difficult to learn and it has a variety of extensions(e. g. XEP) and you will be confused about documentation.
Alternative https://github.com/actorapp/actor-platform
but documentation is obsolete.
We have a OTT application which deliver message to users over XMPP protocol. we using eJabberd to deliver messages. also we have group chats that user can use them with maximum of 200 users.
Now we want to build channels. some think like Telegram channels.
it seems similar application like Viber and Telegram using different infrastructure for channels.
Now the question is what is the best infrastructure for channels (server side and client side)?
where is our start point?
There is many approach you can use to build such system. A tool like ejabberd has been designed to build that type of system. It is scalable and fully extensible through a built in API. This would be a good bet as many OTT services are already built on top of ejabberd.
In my next planned project I suppose to implement an online classroom website in which I want to share a black board (Say a simple text area) among the Tutor and the participating online students {These all are logined through the website}. Whatever the text Tutor writes over the Black board has to be seen by the other participants in Real-time.
I want to use Java as my development platform.
To implement this I started googling on PUSH technology. I read that XMPP implementation servers and XMPP libraries can be used to implement near-realtime applications like collaberative applications/mutiparty games/IM applications etc.,
But I also read about BlazeDS usage for real-time and low-lattency web applications.
My questions are,
what is the difference among these XMPP java based implementation and BlazeDS? Is not both the techs final goal is to achieve low-lattency web apps using PUSH technology?
What is the difference among Comet servers and XMPP Servers? Do they just differ in the way they implement the PUSH technology or any thing else?
I am confused. Please someone explain me these little more so that I will know what I do before I do the things and where to start on next in my project.
Thanks
To answer your first question: No, XMPP's goal is not simply to "achieve low-latency web apps using PUSH technology". XMPP far pre-dates the "realtime web", and is a much more extensive platform than basic comet/push servers.
Features in XMPP that won't typically be in plain push servers include:
Support for non-web clients (including existing desktop clients)
A choice of authentication methods from strong credential-based mechanisms such as SCRAM-SHA-1 to temporary anonymous accounts
Support for federation (communication with other XMPP servers)
Lots of chat-centric capabilities available (contact lists, offline messaging, file transfers) - this can be a bonus or worthless, but most features like these can be disabled in some XMPP servers.
If you are just looking for a component to push messages to website visitors in realtime, and you're using Java which BlazeDS integrates tightly with, then BlazeDS is probably your best choice.
If your push system is part of a larger realtime platform which may involve multiple clients (including non-web for example), multiple languages, and even possibly multiple servers (e.g. you could allow users to use existing XMPP accounts to receive updates) then XMPP is more than likely worth looking into.
I was wondering if it is possible to have a RESTful web service and a bidirectional communication with the clients and server.
In my case the state on the server can change, so the server should send a message to the clients to update themself. Perhaps that's totally against the RESTful idea.
Can I AJAX help me with this issue?
Thanks!
Not really possible under the standard http paradigm, but check out Comet for a possible workaround on that problem and there is alway polling.
The functionality you are after is treated by the concept of web sockets, but they are not mainstream yet.
To keep your solution RESTful you can have the clients poll your service. You can optimize any number of ways, like implementing a special method that lets clients query for changes given a timestamp, then the client just keeps track of when it last checked.
You should take a look at BOSH. BOSH is similar to Comet, but more specific, and I think, there are more reliable implementations.
Though, you will have problems serving multiple users at the same time if you want to use a standard REST service. You should think of some other implementation using nonblocking IO.
There are probably more questions about bosh. Of course, there are websockets now too, but if you need to serve old Browsers, you cannot rely on them.
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