Spark - why we cannot use it in production

I think Spark is brilliant. Well, 90% brilliant anyway. The UI is great but the error checking/reporting just doesn’'t seem as good as other clients. The little things that would make it so much more useable are missing, IMHO

My current top issues are:

  1. Gateway integration.
  • My users who have upgraded from beta 3 to beta 4 cannot use any of the gateways anymore, so they’'re MSN less. No amount of uninstalling and reverting to previous versions seem to work

  • New functionality in the gateway such as notifications when an account is logged in from another location are not reported in Spark, but are in every other client I’'ve tried!

  • When connections to the gateway component are dropped, Spark doesn’'t tell you! I often get presence information logged from the gateway which indicates MSN is offline, but Spark just sits there…

  1. Jingle VoIP

Spark seems so unresponsive. On several occasions calls do not appear on the destination client, despite them appearing in the Spark log!

  1. Reconnections don’‘t work frequently. I often find Spark reconnects but the Roster isn’'t updated so it looks like no-one is logged in.

I realise that sounds like a rant, but I really wanted to recommend Spark as our default client but it’‘s just not robust enough to even contemplate supporting it. Maybe it’‘s because I’'m using beta code, but I suspect not…

Hi Deejay,

Actually, it is because you are using beta code Especially with the Jingle code, we have been doing serious rework of frameworks underneath the covers and with the gateways, the problem of not reporting the presence or other login has not been reported to me. That’‘s what betas are for. Anyhow, I’'ll go ahead and file those issues for the next release, and you keep the feedback coming and Spark will be amazing.

SPARK-612 SPARK-613 SPARK-614

Cheers,

Derek

Message was edited by: ddman

Great, thanks. I really do hope they’'re just teething troubles.

For the 1.0 gateway, it reports the following when logged in from another location:

Whilst thinking about this, would it also be possible to perform a check when attempting to send a message through the gateway that the gateway is actually online?

At the moment (logged) bugs in the gateway service mean that rosters are not always accurate. i.e. the connection to the gateway drops, or someone logs in from another location.

When in that state, Spark knows that, for example, the MSN Gateway item is in the roster as offline. However, it’'ll still allow you to send a message to another roster item that relies on that gateway.

I realise this is not strictly a Spark issue (because the Gateway plug-in should manage the roster better), however, it’'d be great if Spark could report the issue to you rather than blindly sending a message which will never be recieved.

D