Closed mckaygerhard closed 10 years ago
This is a limitation of the current application model. Each window will require an XMPP session. I don't know if it is possible to circumvent this requirement without doing everything again.
You can hack the code to login using non randomized resource. Open converse.php, go to line 134 and delete ". uniqid()". However, your chat partner will get multiple logout and login messages as you move between pages.
umm using non-ramdomized resource can be a workaround.. could we made a config item that can enable that as feature workaround, but this must need another hack..
BUT: _for large xmpp enterprise environment_ the converse.js chat must not show offline users, only online! _this due loading of all of takes some time_, and do not make chances to load and init complete the session...
i have a complete producton environment with a large very huge amount of users, around 3000, and daily have 100~300 online at same time.. loading the session takes several times.. with groups this are very faster but seems that converse.js need a global group, if not many users cannot see others (i must able a global group to solve that)
i'll try some hacks for that, and made a pull request later that u can reviewed and merged or take modifications.. but may take some time due i'm very busy
umm _seems u use prosody!?_ to made u'r development.. i suggest carefully change to another more avanced, noted that prosody do not suppot many of XMPP standars, the most are ejabberd, noted when i make offline .. seems that ejabberd do not understant that converse.js set!
@mckaygerhard
please keep discussion on each issues specific
umm using non-ramdomized resource can be a workaround.. could we made a config item that can enable that as feature workaround, but this must need another hack..
I have plan to use a callable config parameter for generating resource. But this is very low priority.
chat must not show offline users, only online
This is beyond the scope of this Roundcube plugin. You need to open a new issue at converse.js about this.
umm seems u use prosody!? to made u'r development.. i suggest carefully change to another more avanced, noted that prosody do not suppot many of XMPP standars, the most are ejabberd, noted when i make offline .. seems that ejabberd do not understant that converse.js set!
Unfortunately ejabberd doesn't fit my requirement (mass virtual hosting). It will be more helpful if you be more specific about this, and take the issue to the Prosody team.
please keep discussion on each issues specific
umm.. well there many issues that relys in upstream right? so due that, keep track of https://github.com/jcbrand/converse.js/issues/179 due u depends of correct work of converse.js, for made this plugin a piece for serious production enviroments
I have plan to use a callable config parameter for generating resource. But this is very low priority.
well, multiple session cannot be, i'll xplaint to u the importance: if i install chat for many clusters of forums, this chat load all users under a one group, in a enterprise this are not the behabior, many users have leves for a home made environment, this behavior of multiple session are good, in serious nvironment, commercial use as example, this behavior are invalid in my clustering (ejabberd in redundant servers, i mean 16 real machines with 4 nodes, one only have 20 users, others 3 have the 3000 total users in each ejabberd, in conclusion, massive or not are huge), also this made stress to xmpp server _the result its that the chat windows load slowly.. due amount of users!!!!_
This is beyond the scope of this Roundcube plugin. You need to open a new issue at converse.js about this.
u have right, i made https://github.com/jcbrand/converse.js/issues/179 but u'r plugin depends and rely n converse.js so u must have track of the issue, right?
Unfortunately ejabberd doesn't fit my requirement (mass virtual hosting).
i mean that u cannot test and confirm many of the issues reported here.. that makes more hard to solve issues for u, due lack of features that cannot be corroborate..i have ejabberd in production, and openfire in my home ... but i hot nave so time for corroborate all issues..
well, multiple session cannot be,
Unfortunately this is the nature of any web application. You will need a server of some sort, running all the time, to handle multiplexing of pages that belong to the same user session. User can move between pages, login to Roundcube multiple times, or open new page in a new window. And our application need to able to handle that.
It is just the fact that the XMPP protocol and servers we have today already have that feature built-in, so we use it, and we don't have to build a separate multiplexing server from scratch, and our users don't have to run it alongside Roundcube.
If your server cannot cope more than a few sessions on each user, I think you will need to scale up. Upgrade your hardware or rethink your approach.
If what you are saying is that each of your users has all 3000 of your users, then I think this is a rather uncommon use case. We are going to have a limit of what we consider 'too many', whether it is in software or in the mind of your users. But try to talk to upstream nicely.
i mean that u cannot test and confirm many of the issues reported here.. that makes more hard to solve issues for u, due lack of features that cannot be corroborate..i have ejabberd in production, and openfire in my home ... but i hot nave so time for corroborate all issues..
We have users using Openfire and ejabberd successfully. I don't think this problem is related to our choice of XMPP server.
Unfortunately this is the nature of any web application. You will need a server of some sort, running all the time, to handle multiplexing of pages that belong to the same user session. User can move between pages, login to Roundcube multiple times, or open new page in a new window. And our application need to able to handle that.
in enterprise cases, multile session must be controled by system departament, not each users, in a enterprise users not have rights or choices..
in any way its u'r choice.. ... for now its a good plugin but unusefully for enterprise usage, works good in my home configuration
If that's your final definition of 'enterprise', then I'm afraid this software is not for you, or any other 'enterprise' for that matter.
closing this bug.
This plugin creates a new XMPP session on each page rendering in order to support multiple active window.
This make problem in multiple large nodes, specially for ejabberd that limits the number of opened sessions.. in corporate environments (my as exaplme) are limit to 2 sessions per users...
due that, user chat do not show any conected contact in the window...
a workaround are load two session user variables, one for disconecting old rendered sesion (by resource id) and other ofr new conected session at new load!
this bug are very important @priyadi due security implies