I am making a chat system and am new to xmpp technology.For server I am confused among ejabbered , openfire or tigase.I don't know erlang.And am good at java.
I am looking in a case where I have to change a user roster again and again everytimes a user logged in.And that too completely.So I am thinking to control user roster by myself and not by xmpp server.Morever I want to control what to do when a user went idle/busy. And many more.And for security it will be great if it can be done on server side rather than client side.
so how should I customize the xmpp server.And as I need to customise a lot which server should I use?Based on how easy its to learn them and customise them?
I have done similar kinds of customization in Tigase. I will recommend you to choose Tigase if and only if you are looking for high scalability . For Tigase scalability look at Scaling Tigase XMPP server on Amazon EC2 . The other part of Tigase is you need to dig into the code on your own there isn't much help available else than Tigase offical website.
In openfire you can get much community support in term of blogs and tutorials as compared to Tigase. But openfire isn't salable as Tigase. Also Openfire has a wide range of plugins available.
One more thing about Tigase is that Tigase maintains in memory rosters once user gets login.
We used Vysper (http://mina.apache.org/vysper-project/) as our XMPP server for custom clients, actually have it within an OSGi bundle so can hot deploy it.
It has needed some updates and XEP work when we needed something more detailed, but has been a great server to get started with.
Related
I have a requirement of building an chat app using XMPP protocol.I already installed the open-fire and configured MySQL database, i am successfully able to send and receive messages over XMPP. But as per the requirement i want to customized the XMPP and their database, so can anybody guide me how to do that?
Look at the openfire plugin development if you want to extend the functionality of the openfire server. In case if you want to change the openfire server itself, start putting hands in to the source code and read the API spefication docs (perhaps around the defaultauthprovider, hybridauthprovider for databases stuff, not really sure if this can help you).
I know this has been asked a few times, but there seems to be no clear answer ... am searching on this for the past 3 days or more.
There seem to be 2 ways to connect to an Oracle database from an iOS App :
ODBC Client
I need to compile ODBC (which ODBC?) using gcj for ARM. I think this is the hard way, wrought with errors, but possible with quite an effort.
USING WEB SERVICE
Connect from App to webservice and from web service to Oracle DB.
Are these the 2 methods available or any other?
Few questions on the two methods:
a. Which is more secure?
b. Will my company's security department oppose to any of the above?
c. Which is more performant?
d. Which of the above does one normally use?
Webservices are the answer, you do not want people connecting directly to the database from a mobile device. A Webserver will add one extra layer of security as well as the ability to handle simultaneous request without stressing the database directly
a. Which is more secure?
Webservices as explained above
b. Will my company's security department oppose to any of the above?
Yes, security department will insist not to open the oracle port to connect directly, unless they have it already open.
c. Which is more performant?
Webservices, setting up the right cache policies in a webserver can save resources to the database.
d. Which of the above does one normally use?
Webservices, because they offer you great advantages in security and performance, not only that, webservices are reusable and can be accessed by many different platforms, think on the future you might want to serve your application later on Android devices and Webservices will save you a lot of development time.
Many of today's top applications in the market use webservices, think about it.
Google Maps is a great example of how powerful webservices are!
It's not a good idea to connect to your database directly from your app. It can be secure if you create an account that can do nothing but SELECT, but there are some other things to consider.
Why burden the app with the Oracle client?
If you have many users you have to worry about Oracle handling a huge number of simultaneous connections. With a Restful API requests are stateless.
If you decide to change your schema. You'll also have to change your app. When you place a service in between, the app is no longer dependent on the schema.
ODBC connection will require that the Oracle port is open to the Internet, which in vast majority of cases will not be allowed for security and performance reasons. Even if it were, or even if you establish a secure VPN, a direct database access requires that the connection is kept open, which can be problematic when a mobile device can go in and out of the network coverage.
HTTP is far more tolerant to unreliable networks and can be encrypted using SSL (HTTPS). The problem with HTTP is that database do not have direct support for this transport so most people develop dedicated web services.
I work on a project called SlashDB, which automatically constructs RESTful APIs out of databases. For public APIs you would install /db in so called DMZ (a network segment between two firewalls) as described in this blog post.
SlashDB can be configured to allow restricted data access to public users or you can define specific users with varying privileges to data. It is designed as stateless service, which means that you can easily set up multiple nodes behind a load balancer and reverse HTTP proxy for high availability web scale deployments.
Regardless whether you develop the web service by hand or use our product you will achieve better scalablity, performance and security for your solution than by using direct client/server approach. I would even argue that REST APIs should be used internal enterprise data integration solutions but that's a whole new topic.
I am going to repeat what everyone else said, Rest API is the way to go. Do not connect to the database directly. However, there might be a way to connect to your database which I never tried my self.
http://odbcrouter.com/iosvsweb#hn_iOS_Open_Database_Connectivity_SDK
I want to create a web chat application that will just do text chatting. A client will talk to owner. An owner will see the available client to chat with but a client cant see the list of available user he will just click the link and start chat with owner directly.
So i have developed this with cometd and jquery only and its working fine. will that work in real application or should i consider some XMPP server(preferable openfire) also. It is just a text based chat.What are pros and cons of using it with xmpp and without xmpp server.
You can have a look at the CometD benchmark results to have a glimpse of the CometD performance in a case that is worst than yours: in your case a user just chat with the owner, while in the benchmark a user chats with many others.
The CometD benchmark is actually a normal chat application used to perform the benchmark.
With the WebSocket tranport, CometD easily achieves 50k messages/s for 100k clients with a 4 ms median latency.
My experience is that CometD works really well in real applications, and it's probably simpler than XMPP in your case.
Have a look at the CometD documentation and tutorials to get started.
I need to setup chat as a solution for customer service on a website. Openfire and some of it's plugins (fastpath and webchat) were very simple to setup locally and offer all of the customer service experience options I'd need, and will integrate properly into our CRM.
We have a clustered ejabberd instance running for something else. Before I looked into openfire, this was the obvious choice, since it's already been made secure and tailored to our environment. Having to duplicate all of the customer service functionality in an ejabberd module when it comes out of the box with openfire seems like a bad investment of resources.
Eventually, we would like to enable user to user chat as well, and perhaps turn it into a full scale messaging system.
Is it possible and/or recommended, using s2s or some other technique, to share the same database instance between the two different servers ? Does anyone else have any experience running both servers ? I'm sure there will be lots of gotchas if we go down this route, anything obvious ?
In my case, i was obliged to move to openfire for compatibility reasons.
I have a user list in a sql-server database and the external authentification is really hard and not supported for updated versions of ejabberd.
For me openfire is more open to different database and easy to integrate in existing plateforms
I need a webbased group chat client that can interact with various xmpp servers.
I did some research and found muckl , speeqe and tigase minichat but I have one more issue I am deploying my site on shared hosting.
So want to know if anybody has installed any group chat software on shared hosting ( like bluehost ) and which will be the best possible client for the same.
Speeqe is actually 99% javascript, so it will work well on shared hosting. The requirement for Django is just to do things like remember sessions and have nice url structure. It may take a small amount of work to take away Django, but it shouldn't be much.
There are also Django hosting providers, so that might be an option.
Speeqe can also work with any XMPP server, public or self-hosted, etc. I used it many times to join groupchat rooms on arbitrary servers, and there is even an IRC gateway.
For XMPP shared hosting, there are several options now, including a service by Process One: http://process-one.net