Roadblocks Towards company wide acceptance Wildfire 2.44 and Spark 1.1.0

Hello all we are really trying to gather support for this implementation of spark and wildfire yet we are running into a few problems that are really impacting company wide acceptance.

1 - Spark 1.1.0 takes up to 59MB of ram at times (I thought the memory leak was fixed?) compared to other IM clients who average 15MB of ram. We work in a software development firm and people that have 1 Gig of ram are complaining about the mem usage… roadblock towards success

2- We cant seem to disable broadcasts effectively and I dont have to tell you how annoying they are… Ideas suggestions?

3 - Roster groupings dont seem to work ex when you create a group say “friends” sign out and sign in and it will have disapeared. Another roadblock towards company wide acceptance. Ideas? tried spark 1.1.0 and Exodus 9.1.0

4 - Ideas on how to turn off file transfers or throttle the bandwidth? over vpn we might choke the line…

I would like to deploy this configuration to 5,000 users and am experiencing the same “group disappearing” issue you are. This is a real show stopper for us. It’'s a great product, but that is a really big issue multiplied by 5,000.

Hi Cliff,

To answer your questions:

  1. 59mb in Spark. It’'s true that Spark does take up more memory than exodus and psi, this is mostly due to being a pure java app, and of course needing some more profiling on my end ;). However, there is not a memory leak.

  2. Disable broadcasts? You may want to write your own spark plug to remove those options, or I think JBother and Exodus may not have broadcast. I’'m not sure though.

  3. Roster groupings. I’'m not sure exactly what you mean, but by default, groups will not be visible if there are no available users in them. However, in Spark, you can just use the “Show Empty Groups” under the Contacts menu.

  4. File transfer. At least in Spark, you can write a plugin to disable this, however, there might very well be a client that has file transfer capabilities.

Hope this helps, and good luck with whatever works best for you

Cheers,

Derek

Hi Cliff… try Pandion 2.5 as your client. We tried about 6 different IM clients and it settled on it. The users all love it and the women especially love the avatars.

We wanted broadcasts, this is the reason we’‘re using WildFire, for admin broadcasting to all or selected groups of users. There’'s no option to turn it off, but you can turn off the alerts whenever users sign in and sign out.

We also would like to be able to disable all file transfers, but there is no control for that in Pandion nor Wildfire.

We use a customized package of Miranda with a ton of great options. Installed, it’‘s about 8MB disk space, and i’‘m currently at 14MB RAM usage with AIM, Jabber, and MSN running along with various other plugins. We’'ve had great success with this because we were able to skin out the client and make it look really nice.

Jason

1a - Ok As for the groupings we are using a mysql backend and one of my fellow admins thinks he might be able to fix it. We tried the show empty groups option you mentioned and still no go… Groups don’'t stick when you sign out and back in.

1b - What about hashing passwords in the DB…? I dont have to tell you this is a problem… MYSQL I am refering to…

1c - We are going to try QOS from throtteling the bandwidth for file transfers ill let you know how that turns out.

Thank you all for the comments and please do not think that I am displeased with your product… We love it and are interested in contributing to its evolution.

I am interested in submitting several feature requests and might try getting some of our devs to play with the sparkplug dev kit.

In Regards to 1a: Do you mean you are creating the group in the client, signing out and signing in? If so, groups in XMPP are stored based on contacts so each contact in your contact list has a list of groups they are a member of. If the group is not attached to a contact according to XMPP it then does not exsist so it is therefore not being persisted.

In regards to file transfer, we are working on a feature to disable transfers on the server side.

Alex

Woooo wooo the suggestion for groups work… duh why didnt I try that… Any idea about when that feature will be ready to block or throttle file transfers? We are looking to implement but network team is concerned about us bringing certain remote links down due to file transfers.

This is what fixed mine… duhhhh

In Regards to 1a: Do you mean you are creating the group in the client, signing out and signing in? If so, groups in XMPP are stored based on contacts so each contact in your contact list has a list of groups they are a member of. If the group is not attached to a contact according to XMPP it then does not exsist so it is therefore not being persisted.

In regards to file transfer, we are working on a feature to disable transfers on the server side.

Alex

resolved pending issues being addressed in future releases.

  1. Disable broadcasts? You may want to write your own

spark plug to remove those options, or I think

JBother and Exodus may not have broadcast. I’'m not

sure though.

Exodus has. Wonder, does Broadcast disabling really needs a plugin? Some simple checkbox in preferences wount do? Of course then settings.xml should be a read-only for users.

Still shouldnt leave it up to the users to enable or disable…

Well, most of clients were created for a simple user not keeping in mind corporative use. So having a control of everything is normal. Dont know if Spark should be only an enterprise IM with minimal control on the user end. I think many of simple jabbernauts would love it for a nice/clean design and innovative features, so why should developers limit them?

As i think more, there is no need to disable inbuild broadcast on client side. If user doesnt need it, so doesnt use it. So, the best approach - plugin. I think in Spark case it should be possible to do this server side? So, no need to push plugins through Spark Manager. What do you, devs, think? Just a checkbox say in Spark Manager.