Please look into adding the ability for users to view and add configured server transports to the Spark Client. I’'ve been looking at several jabber clients to use with Wildfire (which is pretty cool, by the way) but I want to have all my users access the AIM, MSN, and Yahoo from within their Jabber client, through the wildfire server.
I’‘ve looked at Exodus and Pandion as clients, Exodus seems too complex for the ordinary user, and Pandion, while simpler, has a few shortcomings that I don’‘t like. The Spark interface seems to be the cleanest that I’'ve seen so far.
Thank you for your consideration,
-Al Gartner
I’'m going to second this option. Spark looks like a great client, but we use the MSN transport on our server and while we can communicate with our MSN contacts we cannot add new contacts or add new transport services.
Is this feature planned?
Nathan
I will third this request. We love wildfire and I think Spark is hands-down the best overall client for our environment but for now are stuck using Neos because we must have msn support. Spark works fine with msn contacts if you register the transport and add contacts through Neos, so all that is needed is the function to register with the transport and add contacts for these other transports directly through Spark.
Thanks
I vote for transport support as well. Spark on the whole is an excellent client. Transport support would make it just that much better. I’‘ve got a Wildfire server with all 4 transports installed and I can’'t use them.
And I’‘ll add another request. This is currently the one thing that I am finding most inconvenient about using Spark. While I understand Spark is geared towards businesses, a lot of businesses need to be able to work with the other clients. Not to mention the possibilities of using transports for other internal stuff. I’'m thinking in particular of slowly transitioning an existing IRC network into a Jabber network in a work environment.
As long as these kinds of features can be controlled from the server-side, that’'s fine with me.
The value of a client that may be controlled (as an option) from the server-side would be immense – something like group policy in an Active Directory. I’'d think of it this way – if I have LDAP enabled, any user whose account exists by dint of being a domain user should be controllable – an option to control almost every feature of their client. If Spark is that client, great. The ability to strip it down or burden it with as much stuff as other clients would be great.
A “policyable” client. I haven’‘t seen any clients that even come close to this, but it wouldn’'t be hard to implement. Control could be on a group basis for LDAP users.
I would like to vote for this feature as well. As I have mentioned in another thread, the inability to register with transports in Spark has ended its consideration for use as our corporate IM client.
The problem is this, while the Spark/Wildfire combo work great, and our users really love the Spark interface, they have been using AIM forEVER. It’'s not that they dont want to give it up, they cant, not without the ability to communicate with their external contacts.
It just seems that if Wildfire and Spark are meant “to be together” and I think that they are a good team, then transport/service registration support in Spark should be at the top of the list of enhancements. It would make the Wildfire/Spark combo the best thing going.