I'm implementing a web based chat client using Openfire API with Java.
Things are setup and running smoothly, however, I'm a little confused as to where to store chat history.
From what I've observed, Desktop based clients typically store chat history on the client side filesystem using formats such as xml, txt etc.
On the server side, I have the following options:
Using plain text file
Using json (mongodb, hbase etc)
Using database
But I would like to know which is the best of the above options (or any other ones if you can suggest) in terms of speed and performance.
Thanks.
As mentioned in isnot2bad's comment, you can add server-side message archiving through the use of the Openfire Monitoring Plugin. Once you have that setup you can try using the XEP-0126 to fetch archived 1-to-1 chat messages over XMPP.
Openfire Plugins
Unfortunately I have had nothing but trouble when trying to get messages out of the archive using the stanza's defined in XEP-0136. If you look around the OF support forum you will find other people are also running into problems with this plugin. For example, the plugin will not return the list of conversations in correct order, it will not filter the list of conversations or messages by the date specified by the start attribute, etc. To say the least, the plugin could use some work. As a work around, I've left the plugin in place to take care of inserting the messages into the database, but I've written a custom AJAX solution for the retrieval of the archived messages. I just pull them directly out of OF's database and return them in a JSON object to my client side javascript.
XEP-0136 is due for replacement, it's always been overly complicated. XEP-0313 seeks to replace it, but I haven't found any implementations for OF. Good luck.
Related
During my studies, I have to make a project connected with programming in Java. I learn Java from a few months and I would like to make something interesting (not an application for bank, library, car renting etc). I'm wondering whether it is possible to create real-time web game/application, where you can type something and your friend on another laptop see this message and can send you response? (using internet/Bluetooth) If yes, what I should look for to find information about this type of applications?
Yes, creating something like this is definitely possible. It really will just depend on exactly how you want to implement this (it sounds like you're still not sure EXACTLY what you want, as your description is vague).
What I mean by that, is what do you want as your medium? Would you like the two users to be on their laptops and communicating through their web browsers? Or would you rather have a standalone application that accomplishes this? If so, what Operating Systems will you support? Will it have a graphical user interface, or will it run on the command line?
Let's assume that you want to develop a standalone Windows application that allows the users to exchange messages. Keep in mind that doing this gracefully would involve users logging into your system with authentication, a fairly sophisticated GUI, and lots of encryption for privacy reasons. That being said, a very basic implementation of this could probably be as follows:
You'd have an app that runs locally on the users machine, and also some sort of database backend that your app communicates with. I'd recommend using a mySQL database hosted by Amazons RDS (Here's a tutorial that got me using Javas JDBC library to work with an Amazon RDS database - https://www.youtube.com/watch?v=2i4t-SL1VsU).
Rather than worry about a GUI, I'd suggest trying to get your prototype working on the command line. Your app could preform the following steps when booting up:
Ask user to input the word send followed by a message to send messages ("SEND %MESSAGE%"), or "RECEIVE" to receive messages.
If "SEND %MESSAGE%" is input, add message to database
if "RECEIVE" is input, query the database for all message entries and output them to the user.
You can see that this would accomplish a very crude version of what you asked for, and the devil is in the details. I'd suggest building something very simple like this, and then adding functionality by tweaking and improving features one at a time.
I'm working on a project where I need to stream financial data to a web browser. I got a Java API from the data provider (I'm not strong in Java) with which I can stream the data to my server. When the data comes in I need to do some calculations on it and store it in a MongoDB database and also send it to any connected clients. If I don't want to use Java what are my best options to build a solution? I was thinking about socket.io with Node but not sure how I could monitor the stream and at the same time store the data and stream it to connected clients.
The current technology stack is: MongoDB, Python and Node JS.
Thanks,
Dirk
Sorry that i haven't actually worked with this personally, but at work we used this:
http://www.fluentd.org/
it might more or less accommodate your needs. It might be what you need to catch the data from that Java API that you have and pipe it to wherever you want it.
just as a heads up, plugins aren't really that great, we kinda had a lot problems with them.
I want to add the feature to my Java EE 6-Web-Application (JSF 2.0/EJB 3.1/Hibernate with MySQLDB) that registered users can write messages to each other (e.g. like writing a message on Facebook). I googled around but didn't find a good example. So my question is:
How would you design such a feature?
1) Writing Entity Object with the message to the DB?
2) Using JMS? But wouldn't that be transient?
3) Totally different?
Would be pleased with any kind of input (links, suggestions).
i searched about that before...
if you want to make simple messaging between them, build your own one using database relations
but if you want complex one, so this would a lot of work
-- many people suggest JMS if you want a professional work
but i also recommend Apache ActiveMQ
see the link to Apache ActiveMQ
Facebook uses MQTT (https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920) ... But they cover mobile platforms also ... You can consider using that.
If you are just targeting at taking inputs from browsers and displaying the messages received on refreshing a page, you can go with database approach.
JMS will work for you, but you need a JMS provider for that.
We tried using the JavaMail API for a while, but we sporadically received ArrayIndexOutOfBounds errors documented by this bug report:
http://kenai.com/bugzilla/show_bug.cgi?id=3155
It was marked as fixed, but we continued to have that error actually. Additionally, the performance using JavaMail to retrieve attachments was consistently very slow. On the order of around 10 KB/s even when on the same network as Exchange so we decided to try a different approach.
We found that we were able to get significantly better performance using a Mapi client called MoonRug: http://www.moonrug.com/features.html
This worked substantially better than JavaMail, but we still have errors every now and then connecting to Exchange and downloading attachments (of varying sizes from 3KB to 20MB).
I am starting to question if having Java call Exchange directly is even the right approach for us to take. Does anyone have a recommendation for a better way to do this? We are primarily a java shop, but if there is a different tool or technology that can take emails from Exchange and put them on the file system somewhere for a java process to read and process that is an option for us.
The goal of this application is to take incoming mail on a certain inbox and save them and the attachments to a back end system that users can interact with. We currently do a pull process where we poll the inbox every minute. If there is some way to make this a push process by integrating something into Exchange Server directly to take email and automatically export them onto a file system that would also be an option for us.
You may want to take a look at DavMail. It's Java based, and it does access Exchange. It may or may not provide you with code you can use. Otherwise, it may allow you to use it as a gateway between your JavaMail-based app and Exchange.
I'm well aware of how I can communicate with an outside server using Android. Currently I'm using the relatively new AppEngine Connected Android project to do it, and everything works fairly well. The only thing that I'm concerned with is handling downtime for the server (if at all) and internet loss on the client side.
With that in mind, I have the following questions on an implementation:
What is the standard technique for caching values in a SQLite Database for Android while still trying to constantly receive data from the web-application.
How can I be sure that I have the most up-to-date information when that information is available.
How would I wrap up this logic (of determining which one to pull from and whether or not the data is recent) into a ContentProvider?
Is caching the data even that good of an idea? Or should I simply assume that if the user isn't connected to the internet, then the information isn't readily available.
Good news! There's a android construct built just for doing this kind of stuff, its called a SyncAdapter. This is how all the google apps do database syncing. Plus there's a great google IO video all about using it! It's actually one of my favorites. It gives you a nice really high level overview of how to go about keeping remote resources synced with your server using something called REST.