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.
Related
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.
i'm just a beginner in cometd , and i'm interested and wanted to learn what cometd is and what for it is used i googled it out and found some resource.Under the following link
1.http://docs.cometd.org/reference/installation.html#d0e346.
I tried out with the given demo but i could not able to get the expected output from it. can anybody post some resource url's so that i can learn ?
Disclaimer: I'm the CometD project leader.
CometD is a set of library to write web applications that perform messaging over the web.
Whenever you need to write applications where clients need to react to server-side events, then CometD is a very good choice. Think chat applications, online games, monitoring consoles, collaboration tools, stock trading, etc.
See more at the preface.
CometD ships a JavaScript client library, a Java client library and a Java server library.
This allows you to write applications in the browser with fine-grained logic and control on the server.
The server library, being in Java, leverages the high scalability of the JVM and the powerful asynchronous I/O API that the JVM and the Servlet specification provide.
CometD is transport agnostic: you write your applications using high level APIs, and CometD takes care of delivering the messages over the wire using the best transport available: WebSocket or HTTP, also providing a transparent fallback in case WebSocket does not work.
CometD provides a clustering solution called Oort that allows you to scale horizontally your web applications.
CometD comes with a ton of features and an extended documentation along with tutorials and demos you can use as a starting point for your project.
Join CometD to start hacking on your CometD-based web applications.
The CometD tutorials are currently written for CometD 2.x, but a port to CometD 3.x (the current version of CometD) is currently underway, so that requires a bit of patience.
But you can start right away by following the primer and deploying the demos.
I hope you can get started with CometD with the above references.
Drop an email on the mailing lists for any help you may need.
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.
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.)
I want to implement a chat service on my site, and wonder how to create a simple browser-based IRC client from scratch?
I have a linux box and can install whatever I want on it. Google finds tutors on how to setup an IRC server but no instructions on how to create an IRC client.
(As client languages, I can use JavaScript or Flash.)
As you are already familiar with JavaScript, I would recommend a combination of Node.js, Now.js and node-irc.
Node.js is an application that enables you to run JavaScript server-side and to develop web-applications very fast.
Now.js is a library for Node.js that enables you to RPC between client and server. You can just call a function on the server from your client application and vice-versa; their developers guide is in fact a web chat ;)
node-irc is also a library for node.js that enables you to easily create an IRC client.
Combine these three and you get a very nice, very easy self-coded web chat. For the browser interface, there are many possibilities, including application frameworks like ExtJS, JQueryUI, KendoUI or something easier.
http://www.lightirc.com/
http://wdmedia.org/WFIC/index-en.html#sectiondescription