Great job everybody on the 3.0.0 milestone and thanks to everyone involved!
I have the following feedback:
The Pade Meetings plugin inclusion in its current form needs to be completely rethought. In its current form this plugin adds 700+MB to a Windows user’s profile which is completely unacceptable for an organization that utilizes roaming profiles. The fat either needs to be substantially trimmed or the plugin moved somehow to the C:\Program Files directory so you’re not dragging 700MB for a plugin that may or may not be used across your network when you login or out.
You can’t currently remove or get rid of the Pade plugin. At all. If you delete the files manually Spark just re-downloads them upon next login. If you deactivate it via the plugin manager, and restart, it ignores your choice and upon next Spark startup, Pade is back re-activated. I’m sure this must be a bug.
The installer needs to offer a choice and ask the user if they want to use this or perhaps the Client Control plugin could be utilized for that (not sure at what point Pade is getting downloaded/installed vs. Client Control settings read by Spark). As it is, I can’t find any option anywhere in Spark that controls this behavior of automatically force downloading Pade and dependency libraries, even looking at the properties files. I guess I could try blocking the download at the firewall edge but I am unsure if that will hang Spark while it tries (in vain) to download the libraries.
I am a fan of Pade Meetings but the current implementation in 3.0.0 Beta is…not well thought out for an organization.
I understand your concerns and i didn’t like the size increase either when it was first introduced as SparkMeet many years ago. But i guess to have audio/video there will be some size growth required.
To avoid adding it to user’s profile we would need some significant changes in how Spark operates with plugins. If i block Reversi game in Client Control, the interface is not shown on the chat window, but plugin is still added to user’s profile and extracted. I guess the same will happen with Pade. @ilyaHlevnoy already provided a pull request to add blocking of Pade via Client Control. But it would only be visual. And it also has some issues as currently we only can block plugins without spaces in their names this way. We can rename all such plugins without spaces, but that seems like a dumb workaround, so i am waiting on someone to provide a better solution.
If i deactivate Pade plugin it stays deactivated for me on the next startup. But it would still redownload the files. So this is again only a visual change.
So, this would require to either somehow move Pade to be an internal plugin and put all 150 MB into /lib folder (like LoboBrowser, look and feel, etc.). Or change how Spark operates with disabled plugins (either via Client Control or just deactivating), so it won’t copy and extract plugins into user’s profile if they are blocked.
We would need contributors for this, which are hard to find. And this is why we made it Beta first, to get feedback about Pade and new skin, to see how many users would have concerns, etc. If too many see it as a problem, we probably won’t ship Spark with Pade in the current form. Though, this was the closest Spark was to providing some sort of audio/video option and i think it probably won’t get anything else. And this is what kills Spark in many orgs (on my last job we got rid of Spark, because we needed audio/video) or they don’t even consider Spark when picking a client.
Will mention a few names here, if you have any ideas or maybe just a fix for some part of the problem (like spaces in names of plugins), will be much appreciated. @Michael42@Dele_Olajide@k33ptoo@R87A
Btw, firewall block might work as Dele added a fix mentioned in the changelog. Before that Spark would lock up while downloading Pade files. Now it shouldn’t.
Hey!
I have locked Pade and now the folder size is 290KB.
Let’s hope there are developers who can block plugins without removing the spaces in the name.
Once upon a time, applications on Windows desktop used to be able to install and load data into the C:\Program Files and anywhere on the local C drive. Then came the virus pandemic and organizations restricted applications to download files into user profiles only. That is not changing any time soon.
Over the years with Spark, we have tried every known method possible way to get a web browser embedded in Spark without interfering with the user experience, violating corporate desktop policies or bloating the application. It has been very frustrating to say the least.
It will seem that the solution everyone wants is for someone to a code an efficient WebRTC compatible audio/video media stack in Java for Smack with a very small footprint. That also is not going to happen any time soon.
I am not an expert on Spark source code or it’s plugin architecture. The electron binaries download is done when the plugin is initiated. If anyone know a better place to do that check, a PR is most welcome anytime.
Having been through this cycle so may times, I think we should simply remove the plugin. Anyone who wants or needs it should simply make a very considered decision to use it.
I found a workaround that seems to work for me, which is, the pade.jar file is included in C:\Program Files (x86)\Spark\plugins, if I delete that, Spark won’t (can’t) load it into AppData/Roaming, decompress it and then download the Electron Libraries, etc. automatically each time it is run and therefore the cycle is broken. I can live with that now that I know how to stop it from happening.
IMO at the least there should be an installer with and without it bundled, like you do with and without bundled JRE.
I also want to be super clear that I am a big fan of the work Dele has done with Pade and I am not trying to disparage it; I am just saying that the reality for me as the IT manager is that a bundled plugin that adds 700+MB to each of my employees profiles is a killer.
I haven’t touched the code in over 3 years now. But I remember that Spark plugins can be disabled simply by editing the default.properties file. There is a section there as follows:
DEINSTALL_PLUGINS_DISABLED =
# Put plugins here that you dont want enabled
# comma separated, case insensitive
# names of plugins can be found in the plugin.xml
# example: Fastpath,Jingle Client,Phone Client,Window Flashing Plugin
# default is empty
PLUGIN_BLACKLIST =
# Disable Plugins by entrypoint Class
# Comma seperated, case sensitive
# example org.jivesoftware.fastpath.FastpathPlugin
# default is empty
PLUGIN_BLACKLIST_CLASS =
Also, as another option - in an AD environment you can try to create a group policy that will delete the plugin files from each workstation after Spark is installed. Make sure to delete the plugin files from these locations:
There is a desire to have and maintain less installers. We want to stop bundling JRE at some point (same for Openfire). So having another variant with or without Pade is not ideal. One installer with a choice would be more fitting. Then it should be possible to use install4j varfile to pass in install command with a desired setting.
Is this with Smack 4.4.2? Because on regular Beta it shows ok for me when i login to my test server and igniterealtime.org. Also shows ok with Smack 4.4.2 branch running from source and connecting to igniterealtime.org.
I am guessing somewhere logic is to only show lock when TLS is used. Direct TLS used to be called Old SSL and is probably less secure (and maybe should be removed to avoid confusion, but i don’t know, maybe someone still needs it).
Anyone wants to do it? I kind of have too much already going on with my main job and i don’t have time for this. I mean, creating installers and putting them on the site is easy. But then questions and complains will start There are some minor issues here and there and still not sure about Pade. But i have finalized the changelog for 3.0.0 a while ago (no Smack update, Pade in the current form, no blocking of plugins with spaces in names). Beta blog post can be reused to post about final version.
This is an incomplete list of unpleasant things, but in my opinion, the most critical ones.
Why don’t you want to remove the spaces in the plugin names? This will allow those people who do not need extra plugins (Pade, HttUpload and others) to turn them off.
For example, I’m going to use Pade in the future, video chat is a very cool idea for Spark.
I don’t think this is right, so i don’t want to do it. But as i’ve said, if anyone else wants to do it, talk with Guus and guys, take over the project, start doing changes that you think are right and releasing new versions, etc. I am not going to be involved much going forward.
I kind of have too much already going on with my main job and i don’t have time for this. I mean, creating installers and putting them on the site is easy. But then questions and complains will start 
There are some minor issues here and there and still not sure about Pade. But i have finalized the changelog for 3.0.0 a while ago (no Smack update, Pade in the current form, no blocking of plugins with spaces in names). Beta blog post can be reused to post about final version.