[jitsi-dev] main concerns about Jitsi


#1

Just to summarize the long discussion on debian-devel and give the Jitsi
community an opportunity to respond:

Java
- does it work with GCJ?
- space is limited on disk 1 of Debian
   - can dependencies be reduced?
   - can you split up JARs that contain stuff Jitsi doesn't use?

Linux desktop integration
- what is the current status of integration with GNOME, KDE, XFCE, etc?
- what can be achieved by August (when the Debian desktop decision to
use XFCE will be reviewed)?

UI faults
- this hasn't come up on debian-devel, but I have personally observed
problems with the settings windows not appearing properly. E.g. if I
click to add an account, the window for selecting account type appears
underneath the account list window. This means it is invisible and
unpleasant for people who don't know it is hiding there. My desktop is
configured for focus-follows-mouse and I notice that if I change to
click-to-focus, the windows appear correctly. Focus-follows-mouse is
popular with Linux developers, so this may impact the perception of Jitsi.

ICE for SIP
- this may be the missing link, as it would enable full integration with
mainstream WebRTC (both SIP and XMPP) solutions


#2

Just to summarize the long discussion on debian-devel and give the Jitsi
community an opportunity to respond:

Java
- does it work with GCJ?

I doubt someone has ever tried this. I'm guessing it would run partially if
at least Felix (the OSGi implementation) works.

- space is limited on disk 1 of Debian
   - can dependencies be reduced?

Yes, thanks to the OSGi infrastructure, e.g. the protocols other than SIP
and XMPP could be removed. All that's necessary for this would be to remove
the jars from the directory (and to remove them from a config file to
silence errors).

   - can you split up JARs that contain stuff Jitsi doesn't use?

We already have a lot of JARs, each for a specific task or plugin. I don't
see what could or should be split even more. Are you thinking of something
specific?

Linux desktop integration
- what is the current status of integration with GNOME, KDE, XFCE, etc?

We use the JDIC components that went into Java 1.6 with all its drawbacks.
This is especially noticeable with the non-transparent tray icon. We haven't
done anything special for a specific Linux desktop environment (other than
maybe a little hack here and there).

- what can be achieved by August (when the Debian desktop decision to
use XFCE will be reviewed)?

We had put up a project for a new systray implementation as part of GSoC,
but at least on the mailing list this hasn't drawn much attention. (See next
answer too.)

UI faults
- this hasn't come up on debian-devel, but I have personally observed
problems with the settings windows not appearing properly. E.g. if I
click to add an account, the window for selecting account type appears
underneath the account list window. This means it is invisible and
unpleasant for people who don't know it is hiding there. My desktop is
configured for focus-follows-mouse and I notice that if I change to
click-to-focus, the windows appear correctly. Focus-follows-mouse is
popular with Linux developers, so this may impact the perception of Jitsi.

We want to switch the whole UI from Swing to HTML5, based on Chromium
Embedded Framework. As dependencies were also mentioned a lot, this will
certainly not make it any easier. On the other hand, I guess it will solve a
lot of the problems we currently have, like the focus issues you mentioned.
Given this UI framework change, it's unlikely we're going to put much effort
into the existing Swing UI.

ICE for SIP
- this may be the missing link, as it would enable full integration with
mainstream WebRTC (both SIP and XMPP) solutions

Emil is working on it... :slight_smile:
Parts of it are already in master.

Some other points that come to mind:
- Bonjour support is still in the master tree, but disabled because it's not
stable and not maintained.
- Rolf Leggewie recently complained about our build setup for Debian.
- What are those amazing integrations of Empathy/Telepathy the others were
talking about?

Ingo


#3

Hey Daniel,

Just to summarize the long discussion on debian-devel and give the Jitsi
community an opportunity to respond:

Thanks for doing that and thanks very much for the suggestion!

Java

Yes. Not much we can use about that even though many people seem to be opposing it on principle.

- does it work with GCJ?

Last I checked it didn't. That was quite a while ago though, but what exactly would be the advantage of GCJ over OpenJDK?

- space is limited on disk 1 of Debian
    - can dependencies be reduced?
    - can you split up JARs that contain stuff Jitsi doesn't use?

We could maybe lose some of the stuff but I don't believe that more than 10% would be easy and 20% would probably be the maximum.

Linux desktop integration
- what is the current status of integration with GNOME, KDE, XFCE, etc?
- what can be achieved by August (when the Debian desktop decision to
use XFCE will be reviewed)?

We are likely to take a GSoC project on the subject of the systray. I think it is generally achievable if someone puts the resources on it.

UI faults
- this hasn't come up on debian-devel, but I have personally observed
problems with the settings windows not appearing properly. E.g. if I
click to add an account, the window for selecting account type appears
underneath the account list window. This means it is invisible and
unpleasant for people who don't know it is hiding there. My desktop is
configured for focus-follows-mouse and I notice that if I change to
click-to-focus, the windows appear correctly. Focus-follows-mouse is
popular with Linux developers, so this may impact the perception of Jitsi.

We'd need to look into this. It probably wouldn't be that much of an issue.

ICE for SIP
- this may be the missing link, as it would enable full integration with
mainstream WebRTC (both SIP and XMPP) solutions

We are about 10 work days shy of having that. If that's what's standing between Jitsi and Debian Adoption, then you can consider it done.

Cheers,
Emil

···

On 31.03.14, 20:51, Daniel Pocock wrote:

--
https://jitsi.org


#4

Just to summarize the long discussion on debian-devel and give the Jitsi
community an opportunity to respond:

Java
- does it work with GCJ?

I doubt someone has ever tried this. I'm guessing it would run partially if
at least Felix (the OSGi implementation) works.

- space is limited on disk 1 of Debian
   - can dependencies be reduced?

Yes, thanks to the OSGi infrastructure, e.g. the protocols other than SIP
and XMPP could be removed. All that's necessary for this would be to remove
the jars from the directory (and to remove them from a config file to
silence errors).

That is good news - the package can recommend and suggest JARs that are
not mandatory dependencies, so people will still have an easy way to get
that stuff

You could also have meta packages:

jitsi-base
jitsi-minimal - with SIP and XMPP
jitsi-all - with all modules

and then individual packages

jitsi-mod-sip
...

   - can you split up JARs that contain stuff Jitsi doesn't use?

We already have a lot of JARs, each for a specific task or plugin. I don't
see what could or should be split even more. Are you thinking of something
specific?

There was no specific example in mind. However, I do know that
sometimes people use just 1% of classes from a JAR library and then the
other 99% and the related dependencies are wasted.

Linux desktop integration
- what is the current status of integration with GNOME, KDE, XFCE, etc?

We use the JDIC components that went into Java 1.6 with all its drawbacks.
This is especially noticeable with the non-transparent tray icon. We haven't
done anything special for a specific Linux desktop environment (other than
maybe a little hack here and there).

- what can be achieved by August (when the Debian desktop decision to
use XFCE will be reviewed)?

We had put up a project for a new systray implementation as part of GSoC,
but at least on the mailing list this hasn't drawn much attention. (See next
answer too.)

UI faults
- this hasn't come up on debian-devel, but I have personally observed
problems with the settings windows not appearing properly. E.g. if I
click to add an account, the window for selecting account type appears
underneath the account list window. This means it is invisible and
unpleasant for people who don't know it is hiding there. My desktop is
configured for focus-follows-mouse and I notice that if I change to
click-to-focus, the windows appear correctly. Focus-follows-mouse is
popular with Linux developers, so this may impact the perception of Jitsi.

We want to switch the whole UI from Swing to HTML5, based on Chromium
Embedded Framework. As dependencies were also mentioned a lot, this will
certainly not make it any easier. On the other hand, I guess it will solve a
lot of the problems we currently have, like the focus issues you mentioned.
Given this UI framework change, it's unlikely we're going to put much effort
into the existing Swing UI.

ICE for SIP
- this may be the missing link, as it would enable full integration with
mainstream WebRTC (both SIP and XMPP) solutions

Emil is working on it... :slight_smile:
Parts of it are already in master.

Some other points that come to mind:
- Bonjour support is still in the master tree, but disabled because it's not
stable and not maintained.

Yes, that is something else that has been requested on debian-devel

- Rolf Leggewie recently complained about our build setup for Debian.

I avoided complaining about that so far - I need to review the
dependency JARs and see if I can help you get them into standalone packages.

- What are those amazing integrations of Empathy/Telepathy the others were
talking about?

I built a Debian Live DVD for several people, each with a pre-configured
XMPP account in Empathy. I posted the DVDs out to them and they can
just boot and call me.

So, Empathy does work, but that is a very specific use case where I
control the server and I control both ends of the connection to
guarantee that it works.

Empathy is great as a quick way to start doing XMPP chat - it is really
quick to set up and just works. For VoIP, however, it is limited by the
lack of TURN support and the demands of WebRTC.

···

On 31/03/14 21:29, Ingo Bauersachs wrote:


#5

Hey Daniel,

Just to summarize the long discussion on debian-devel and give the Jitsi
community an opportunity to respond:

Thanks for doing that and thanks very much for the suggestion!

Java

Yes. Not much we can use about that even though many people seem to be
opposing it on principle.

- does it work with GCJ?

Last I checked it didn't. That was quite a while ago though, but what
exactly would be the advantage of GCJ over OpenJDK?

Only one person suggested GCJ - OpenJDK should be sufficient

- space is limited on disk 1 of Debian
    - can dependencies be reduced?
    - can you split up JARs that contain stuff Jitsi doesn't use?

We could maybe lose some of the stuff but I don't believe that more
than 10% would be easy and 20% would probably be the maximum.

This is always an awkward question

10% may seem like a lot of effort for very little benefit

However, if that 10% is 10MB, that corresponds to several whole packages
on the installer CD 1

As discussed in the other reply, modularizing (e.g. having separate
packages for each protocol and only installing the SIP and XMPP related
stuff on disc 1) could help

Linux desktop integration
- what is the current status of integration with GNOME, KDE, XFCE, etc?
- what can be achieved by August (when the Debian desktop decision to
use XFCE will be reviewed)?

We are likely to take a GSoC project on the subject of the systray. I
think it is generally achievable if someone puts the resources on it.

UI faults
- this hasn't come up on debian-devel, but I have personally observed
problems with the settings windows not appearing properly. E.g. if I
click to add an account, the window for selecting account type appears
underneath the account list window. This means it is invisible and
unpleasant for people who don't know it is hiding there. My desktop is
configured for focus-follows-mouse and I notice that if I change to
click-to-focus, the windows appear correctly. Focus-follows-mouse is
popular with Linux developers, so this may impact the perception of
Jitsi.

We'd need to look into this. It probably wouldn't be that much of an
issue.

I'm guessing you can send some signal to the window to make it rise to
the top

ICE for SIP
- this may be the missing link, as it would enable full integration with
mainstream WebRTC (both SIP and XMPP) solutions

We are about 10 work days shy of having that. If that's what's
standing between Jitsi and Debian Adoption, then you can consider it
done.

I wouldn't guarantee that - but it does give me a lot more evidence that
Jitsi is the only full softphone to work with hundreds of millions of
WebRTC browsers. It would be very easy to demonstrate an rtc.debian.org
user calling a Jitsi user.

···

On 01/04/14 20:50, Emil Ivov wrote:

On 31.03.14, 20:51, Daniel Pocock wrote:


#6

You could also have meta packages:

jitsi-base
jitsi-minimal - with SIP and XMPP
jitsi-all - with all modules

and then individual packages

jitsi-mod-sip
...

I guess we would need serious help with that - Debian bundling is not really
our expertise.

   - can you split up JARs that contain stuff Jitsi doesn't use?

We already have a lot of JARs, each for a specific task or plugin. I

don't

see what could or should be split even more. Are you thinking of

something

specific?

There was no specific example in mind. However, I do know that
sometimes people use just 1% of classes from a JAR library and then the
other 99% and the related dependencies are wasted.

Well, I was talking about our own jars. When it comes to external
dependencies, there's most probably a lot in them that we don't use. It
would probably be possible to strip out stuff for those libs we deliver
embedded, but for those that are already packaged as Debian libraries, I
don't know how that should work.

[...]

Some other points that come to mind: - Bonjour support is still in the
master tree, but disabled because it's not stable and not maintained.

Yes, that is something else that has been requested on debian-devel

- Rolf Leggewie recently complained about our build setup for Debian.

I avoided complaining about that so far - I need to review the
dependency JARs and see if I can help you get them into standalone

packages.

We really have a lot of dependencies, and most of the embedded ones are like
this because the argument was that probably no other package will ever use
them.
And then there's was also the discussion over our contributor agreement...

- What are those amazing integrations of Empathy/Telepathy the others

were

talking about?

I built a Debian Live DVD for several people, each with a pre-configured
XMPP account in Empathy. I posted the DVDs out to them and they can
just boot and call me.

Well, that's what our provisioning plugin does.

So, Empathy does work, but that is a very specific use case where I
control the server and I control both ends of the connection to
guarantee that it works.

Empathy is great as a quick way to start doing XMPP chat - it is really
quick to set up and just works. For VoIP, however, it is limited by the
lack of TURN support and the demands of WebRTC.

My question was more about the apparently very good desktop integration of
that client.

Ingo


#7

You could also have meta packages:

jitsi-base
jitsi-minimal - with SIP and XMPP
jitsi-all - with all modules

and then individual packages

jitsi-mod-sip
...

I guess we would need serious help with that - Debian bundling is not really
our expertise.

This is one of the easiest things to do - just as long as Jitsi is
already modular (e.g. different protocols in different JARs), we just
have to map them to different packages

   - can you split up JARs that contain stuff Jitsi doesn't use?

We already have a lot of JARs, each for a specific task or plugin. I

don't

see what could or should be split even more. Are you thinking of

something

specific?

There was no specific example in mind. However, I do know that
sometimes people use just 1% of classes from a JAR library and then the
other 99% and the related dependencies are wasted.

Well, I was talking about our own jars. When it comes to external
dependencies, there's most probably a lot in them that we don't use. It
would probably be possible to strip out stuff for those libs we deliver
embedded, but for those that are already packaged as Debian libraries, I
don't know how that should work.

[...]

Some other points that come to mind: - Bonjour support is still in the
master tree, but disabled because it's not stable and not maintained.

Yes, that is something else that has been requested on debian-devel

- Rolf Leggewie recently complained about our build setup for Debian.

I avoided complaining about that so far - I need to review the
dependency JARs and see if I can help you get them into standalone

packages.

We really have a lot of dependencies, and most of the embedded ones are like
this because the argument was that probably no other package will ever use
them.
And then there's was also the discussion over our contributor agreement...

This could be a chicken-and-egg situation though - once those
dependencies are available standalone, other people may be more likely
to use them

I already use ice4j in Lumicall for example (although that is Android,
not Debian, of course)

Anyhow, separating them is not really a hard problem, it is just a
slightly time consuming thing to do.

- What are those amazing integrations of Empathy/Telepathy the others

were

talking about?

I built a Debian Live DVD for several people, each with a pre-configured
XMPP account in Empathy. I posted the DVDs out to them and they can
just boot and call me.

Well, that's what our provisioning plugin does.

I see no reason why Jitsi wouldn't work exactly the same way as Empathy
on a Debian Live DVD - even without the provisioning features, it is
possible to run Jitsi once to create a home directory config and copy
that in to the DVD image for a user.

So, Empathy does work, but that is a very specific use case where I
control the server and I control both ends of the connection to
guarantee that it works.

Empathy is great as a quick way to start doing XMPP chat - it is really
quick to set up and just works. For VoIP, however, it is limited by the
lack of TURN support and the demands of WebRTC.

My question was more about the apparently very good desktop integration of
that client.

Desktop integration isn't just about GUI

There are a whole suite of APIs in Linux desktops now, e.g. the DBus
messaging mechanism

This page gives more hints about how Empathy/Telepathy integrate, notice
the diagram:

http://telepathy.freedesktop.org/wiki/

and more advanced stuff like this:

http://telepathy.freedesktop.org/wiki/Tubes/

I wouldn't expect Jitsi can or should do all of that though

···

On 31/03/14 22:43, Ingo Bauersachs wrote: