Dele Olajide wrote:
This is very interesting! Could you elaborate a bit more? If it is planned for the core library, is it agreed with Jitsi development team already? Will it be based on Rayo or any extensions of Colibri or may be something else? Do you have a rough estimate when it will be introduced in the core library (e.g. this quarter, this year)? I’d be greatful for any information on this topic.
Thanks for this link! I was not aware of it. Yes. It seems to go in the right direction.
Also, you look at an alternative way for the third party focus control. See https://github.com/jitsi/jitsi-meet/issues/34
Well, this approach relies too much on the client-side logic. This is why I’m trying to avoid this kind of solutions. I want my clients to be as dumb as possible, so that it is easy to create new Web clients or standalone apps.
VirtualConnection was used to implement a virtual user, you could use Smack or any client library instead.
Ah, OK. That explains a few things.
MUCEventListener allowed me to get global MUC join/leave room events. You really don’t need that to implement a third party focus especially if you decide to use an alternative room implementation as wevryone does with WebRTC.
Exactly. I came to the same conclusion today. Basically, I already have a non-XMPP based way of chat control and I receive corresponding events. I just need to use them instead of what MUCEventListener reports.
For a very small footprint XMPP that is even more up to date than Openfire, take a look at Prosdy.
Yes. I already started looking at it. It is really small. But getting MUCEventListener-like events from it could be problematic, unless you want to implement support for chat rooms as an external component. But Prosody is still nice a light-weight XMPP server that can be used for delivering XMPP messages.
Actually, I went even a bit further in the direction of eliminating a need for an XMPP server. I created an experimantal ExternalSocketComponent using Whack. It is like ExternalComponent and can be started either to receive connections or to establish connections to remote ExternalSocketComponent. Internally, it wraps a usual Component, just like ExternalComponent does. The difference is that now two components may talk to each other directly via sockets. They do not need any XMPP server to exchange XMPP packets between each other. In scenarios, where you are more interested in the XMPP payload, but not so much in how it was delivered, it could be useful. Obviously, it misses many features of a real XMPP server, e.g. presence handling, chat rooms, etc. To test this approach, I took the vanilla Jitsi Video Bridge component and wrapped it into an ExternalSocketComponent. And it seems to work just fine. I can now connect from my client to the VideoBridge directly over a socket, bypassing any XMPP server.