Wildfire Roadmap

Hey all,

We’‘ve been working on plans for the next Wildfire release this week, so I wanted to give everyone some details. First, 3.0.1 will be out next Thursday. It will include a number of bug fixes since the 3.0.0 release. Then, it’'s on to 3.1 work, which should be about two months away. The major priorities for 3.1:

  • Easier LDAP integration. We’'d like to get LDAP integration into the setup tool and also have an admin console page that allows configure changes. Whenever possible, we want the tool to auto-detect the best settings to make LDAP integration fundamentally easier. Issue: JM-193.

  • Better native installers. Our priorities are a Mac OS X DMG, Ubuntu/Debian package, and RPM for Fedora/RedHat. There are two primary goals here. First, to make Wildfire even easier to install. The tar.gz package just isn’'t up to our standards, and the current RPM leaves a lot to be desired. Second, we can make upgrades a lot easier by going with native packages. Issues: JM-765, JM-766, JM-767.

  • Easier gateways. Although the Py-* gateways work great, setting them up and configuring them can be a pain, especially for operating systems without native Python support. We also believe that interoperability with other networks should be free and easy. So, we’‘re teaming up with Daniel Henninger to work on a gateway plugin for Wildfire. The first priority is AIM/ICQ support, but hopefully other protocols will follow soon after. I can’‘t promise how much of this work will get done for 3.1, but we’'ll do our best. Issue: JM-761.

Of course, we’‘ll include a bunch of other smaller features and fixes. We’‘re also planning on some great improvements to Wildfire Enterprise. If you have feedback about these priorities, let me know. Are there things we’'re forgetting?

Best Regards,

Matt

matt wrote:

Hey all,

If you have feedback about these priorities, let me know. Are there things we’'re forgetting?

Best Regards,

Matt

Hi,

what about some “Popular Issues” like JM-356 (JEP-0124 HTTP Binding) or JM-65 (Roster Management in Admin Console) ?

JM-356 would really help to setup a webchat like JWchat without installing Tomcat or something like this.

I don’‘t care at all for easier installation – the .tar.gz works fine for me. It would be nice if I could use emerge on my Gentoo box, but it seems that won’‘t work for a while because their java-1.5 hasn’'t gone stable yet (and I mostly just run the stable tree). Integrated transports would sure be nice, but…

I really think virtual domains should be on the priority list (I sure hope that’‘s not an Enterprise thing only!!!). Apparently, I’'m not the only one, either.

Also, some of the bigger JEP’'s would be pretty cool: HTTP Binding (JEP-02124) and possibly Advanced Message Processing (JEP-0079).

Hi Matt,

I have no idea about DMG but for *nix it may be much better to supply a good installation guide (or an install.sh script) together with the .tar.gz version so one can install it easily.

As it is open source it may be possible that some individual decides to create an Ubuntu-Wildfire, DMG-Wildfire or RPM-Wildfire project with the goal to deliver a “simple” Wildfire installer which requires root access to install it. So you could keep the focus on the Wildfire Java development and wouldn’'t have to care about installers for different plattforms.

LG

Hey guys,

HTTP Binding is one of the items that’‘s likely to fit in for 3.1 as well. Virtual domains is something we’‘d love to get done, but it’'s going to take some time, as it will be a large effort.

On the installers – I didn’‘t expect that issue to be as popular with existing Wildfire users. You guys already know how to deal with the tar.gz. But for Wildfire to be a success in being a viable open alternative to Microsoft’‘s LCS, it has to spread like it’‘s name. Right now, only the Windows install is extremely easy and that’'s just not good enough. With better installers, we hope to attract a larger variety of new users.

Regards,

Matt

matt wrote:

Hey guys,

HTTP Binding is one of the items that’'s likely to fit in for 3.1 as well.

I’'m happy to hear this.

matt wrote:

With better installers, we hope to attract a larger variety of new users.

That is true, but creating installers for every popular platform is a very extensive work and maintenance.

So the thoughts from LG are a good alternative.

matt wrote:

With better installers, we hope to attract a larger variety of new users.

That is true, but creating installers for every popular platform is a very extensive work and maintenance.

So the thoughts from LG are a good alternative.

Wildfire has been Open Source for two years, and so far nobody has stepped up to the plate to create native installers. That’‘s why we’'re taking on the burden for a few key platforms. Of course, we could never maintain installers for every possible platform, but Windows, RPM, Ubuntu/Debian, and OS X (along with the .zip and .tar.gz builds) seems like it should cover quite a few cases.

Regards,

Matt

Hi Matt,

a good install.sh script will work for every *nix operating system. I assume that Solaris or AIX users may also want to get an installer for their operating system.

One could also offer a root_pre.sh script to add a user and a group, and the rc scripts for linux.

And as you like to offer diff-updates an update.sh script may complete a small set of scripts which are really easy to maintain compared to installers and update packages for many plattforms.

LG

matt wrote:

Wildfire has been Open Source for two years, and so far nobody has stepped up to the plate to create native installers. That’‘s why we’'re taking on the burden for a few key platforms. Of course, we could never maintain installers for every possible platform, but Windows, RPM, Ubuntu/Debian, and OS X (along with the .zip and .tar.gz builds) seems like it should cover quite a few cases.

I guess I don’‘t really see that. Sure, on Windows everyone expects an installer, but on anything Linux- or BSD-based you either use the native package management (e.g. apt-get or emerge or ports or fink or whatever) and have the distribution take care of that (as it’'s straightforward enough, it seems) or you deliver a .tar.gz which builds with ./configue && make && make install (or its ant-based equivalent, possibly).

Note that installers are loathed on Mac OS X. The best install option for this platform would be a zip-file, which includes a jar you can double-click (which launches it like java -jar does). An additional plus would be a setup interface for creating that wildfire.xml-file, but ideally, the application could detect its own install location and just set the wildfire home to the proper place automatically, so no setup is needed. Add a weblink file to http://localhost:9090/, and everybody is happy.

anlumo,

I agree in general on installers in OS X. That’'s why the Spark installer is just a DMG file with the executable in it. However, I think Wildfire is a different story:

  • As a server process, putting it in a standard directory makes sense.

  • Simple pkg installers inside a DMG really aren’'t that bad.

  • We’'ll be installing a prefrences pane that lets you start and stop the server and install/uninstall it as a service. I attached a screenshot so you can see what it might look like. For developers, double clicking on a JAR file to start the app is fine. However, for production use, easy installation as a service is critical.

My Ubuntu experiments are also going pretty well. I attached a screenshot.

Regards,

Matt

Manuzhai wrote:

on anything Linux- or BSD-based you either use the native package management (e.g. apt-get or emerge or ports or fink or whatever) and have the distribution take care of that

Yep, apt-get support is exactly what I want. Why should someone have to come to jivesoftware.org, download the tar.gz, extract it, run a script, then do some manual integration work with Java when instead they can just type apt-get wildfire?

-Matt

I disagree with installers being “loathed” on Mac OS X. This is the first time I’‘ve ever heard of an installer being “loathed” in Mac OS X. Take the simple installers for MySQL. There’'s a lot of nice installers for that. It even has a nifty Preference Panel integration for starting and stopping it. On top of that, an installer can handle the OS X daemon type tasks like setting it up to work with launchd and auto-run on startup and such.

All in all, most installers are easy to maintain once you’‘ve done them the first time. RPMs are typically nothing more than a simple version change and maybe changelog update. The .pkg/.dmg stuff for OS X already is made via a build process. All in all, they’‘re more or less a "do it once and you’'re done" type of situation.

I would certainly appreciate seeing the installers show up. I even happen to use the currently RPMs for my local installs. (and at work, build a custom RPM for each update) Color me confused to hear such dismay over these new offerings.

jadestorm wrote:

I disagree with installers being “loathed” on Mac OS X. This is the first time I’‘ve ever heard of an installer being “loathed” in Mac OS X. Take the simple installers for MySQL. There’'s a lot of nice installers for that. It even has a nifty Preference Panel integration for starting and stopping it. On top of that, an installer can handle the OS X daemon type tasks like setting it up to work with launchd and auto-run on startup and such.

Well, of course common practice is a bit different when it comes to background tasks, but you might want to look into OSXvnc on how they do it.

All in all, most installers are easy to maintain once you’'ve done them the first time.

Not for the users, files get spit all over the system and you have no control at all. Maybe it’‘s worse on the Mac because there’‘s no automatic way to uninstall… All apps are just a self-contained folder, so there’'s no real need for it.

Hi Matt,

do you offer also a Curses gui? It makes me grooozel (It’'s creepy) to see an X-Server running an a server.

Using an installer makes it often impossible to install two different versions or two instances of the product on a server, currently one can install three Wildfire instances to support three domains.

LG

LG,

For Linux, what we’‘re talking about is a Debian package and a better RPM. No GUI/X-server required. And, please keep using the tar.gz if you prefer it, it won’'t go away.

-Matt

Hi Matt

As you say, the installer on Windows works perfectly. With regards to features, I too would like to see an integrated web based client similar to fastpath maybe even based on Spark and roster management similar to Ejabberd which is pretty powerful.

In addition, I saw some comment regarding ad hoc commands - can you give any details of how they work / how to use them ?

Keep up the great work.

Martyn

Most of the mac admins I’‘ve worked with here and there administer their servers remotely via something like Apple Remote Desktop and end up with a GUI they can do most of their administrative tasks from. I do agree that, if you are someone who administers your server via SSH or any myriad of command line tools, then you are likely to not get anything out of the package. But then the tarball should do the trick for those folk. All in all, I don’‘t see what the harm is in offering the installer package as an option at least. It’‘s not like they’'re planning on ditching the tarball. =D

I’‘ve administrated my router running Mac OS X at home for a few years using VNC whenever necessary, and it was shear horror! It was far too slow to be useful for anything (it had a lag of > 1sec, and that’'s on 100MBit/s switched Ethernet). That was the primary reason I switched to Linux there… Windows Remote Desktop is ok, but remote administration on Mac OS X is simply not possible via something like VNC or ARD. Mac OS X Server comes with administration apps that run locally, but are connected to the server via the network.

From what I’'ve seen, Apple Remote Desktop is plenty better than VNC. =)

It’'s also plenty more expensive. =/

Looking over their shoulds, it seems to be about as fast as Windows Remote Desktop.

I use VNC to connect to one of my machines at work and … yeah. It doesn’‘t even have to travel far on the network (to switch and back) and it’'s still not what I would call “fun”.