Request: Spark client with embedded Wildfire server


I have a suggestion/request. I would love to have a version of the Spark client that has an embedded version of the Wildfire server included. This would serve two very beneficial purposes…

  1. This version would act as an easy to use demo of the full Spark/Wildfire client/server functionality. This would basically be an IM client that connects to itself as the server. The user could then evaluate all the functionality of the server via a web browser through a local link (possibly launched from the client menu).

  2. This would be a great replacement for “client-only” IM programs, increasing the popularity of Spark/Wildfire. Because of its well designed and intuitive interface, many “client-only” users would be attracted to Spark as an alternate to clients such as AIM/ICQ, MSN, Yahoo, GoogleTalk/Jabber, Gaim, Adium, Trillian, etc. At the same time, organizations would become familiar with Wildfire when they find the need to secure/manage existing IM services (AIM/ICQ, MSN, Yahoo, GoogleTalk/Jabber, etc).

The Spark client with embedded Wildfire server should come with a default configuration that runs “out of the box”. For example, the backing database could be an instance of embedded HSQLDB or H2 (, and all the popular transport layers should be installed (AIM/ICQ, MSN, Yahoo, GoogleTalk/Jabber, etc).

What do you think?

Thank you.

Here are my thoughts.

1.) Both of the products are supposed to run separate from each other, and they don’‘t always follow the same release schedule. Some server components are beta, some client components are beta. Trial by fire, so to speak, isn’'t going to be well-served in making it a single application since they both serve different purposes.

Besides, installing both products is super easy.

I do see how you may be limited if you want to test the login for your domain name. The simple answer to that is to specify the spark client connect to a specific server, probably localhost for your eval purposes.

2.) The most popular client-only interfaces have jumped through multiple flaming hoops to get around firewalls, NAT, and other network obstacles. They can do this because they’'re proprietary and can do whatever they want. Since XMPP is standards-based, there are actual rules to follow for everyone to play nice.

Part of that rule is that server-to-server connections rely on DNS to function. The average user behind a DSL or cable modem isn’'t likely to know anything about making SRV records (or pointing the general A record) to a dynamic IP address and doing the appropriate port forwarding, rendering any server connectivity pretty dicey if at all possible… All of that assumes they have a domain name at all.

There are much better clients for users who need everything in one shop.

3.) (I added this) Those things said, the community is much better served by first getting people onto an XMPP-compatible network, of which GMail is the largest and easiest to get onto. At the same time, those of us who do have domains under our control can make XMPP services available to our user base.

If we can gain enough momentum here, and another one of the big guys (Y!, AIM, ICQ) opens up an XMPP s2s transport, then the rest will fall in line and do the same.


a normal “Windows” user may also fail to open the firewall to allow other clients to connect - and a localhost demo is a little bit weird. But it’‘s really easy to install both products on one computer, so there’'s really no need to have a bundle.


Fair enough

Thank you for your thoughts and taking my suggestions into consideration.