Dave;
thanks loads for your feedback. :)
What are the drawbacks you've found? I'd like to address these if
possible. I'd be especially interested to know if you're still seeing
issues on the latest version (4.1.6), and if you've looked at the 4.2
Beta which was released last Friday.
One of the most annoying issues actually is that group chat history
doesn't seem to "work well": There doesn't seem to be a (server-sided?)
understanding of which messages I have already seen and which I haven't.
I can easily reproduce this in my environment (using jitsi on the
desktop and Conversations on the mobile device): Whenever I get back
"online" on the mobile device after a couple of days or weeks, I will
have a longer period of being notified with "new" messages which
actually are old messages I have already seen on another client. It
happens for 1:1 chats as well as for conferences / group messages.
I'm always a bit lost here in whether these things are client or server
limitations, but this doesn't seem to happen with any other of my XMPP
accounts.
I'd be curious to know what protocols were in use here. Openfire
doesn't do anything with file transfers, so it's likely this is a
client-side issue - but what Openfire does do is present a SOCKS5
proxy for clients to use. It's possible, I suppose, that this is
causing problems or has bugs, but I'm unaware of any reports.
There are two things to that:
- Currently we are using what seems XMPP P2P file transfer. Right now we
managed to get this to work only on desktops when both clients are on
jitsi. It never worked from or to any other client - the user by then
would be able to accept an incoming file transfer request which still
would result in a message that the request has been canceled (and file
not been sent).
- Some of our colleagues are dealing with Slack in other projects.
Expectation towards file transfer especially in group chats pretty much
is that of Slack or (talking images) of any other messenger: I don't
want to have files stored anywhere on disk but want to have them
permanently available while browsing the history, best of all inline.
This, today, is one of the most painful things in general using XMPP.
Having them displayed inline seems a client issue but keeping these
files somewhere around and permanently available seems a server-sided
thing.
Openfire doesn't support the HTTP file upload capability (but I know
Guus has a plugin in development for this).
That seems what we might need then.
I'm confident in saying that Openfire's support of Active Directory
and LDAP remains leading.
Yes I've seen this, so far I hesitated doing so as (as far as I see
things) it requires changing the user database in openfire, as well, and
as I'm unsure whether we should completely replace this and move to
another runtime, so far I didn't do so. However I wanted to keep the
amount of configuration of these things in different systems low here -
and pam+winbind for AD account and group mapping is already "there" on
the machines. ;)
Thanks again for your hints; I'll take a look at the other options and,
too, check out openfire 4.2 beta.
Best,
Kristian
