<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> Does Windows really require a full-blown installer? It might be easier to<br>
> simply offer a zip and require installing the stock Erlang runtime package<br>
> separately, maybe with a hint to version compatibility or recommendation.<br>
> It's not *that* hard.<br>
<br>
</div>Holger, you're preaching to the converted, especially being somebody<br>
who has never installed Rabbit themselves.<br>
<br>
But personally I've only run Rabbit on BSD, Arch and OSX, so I am not<br>
the right person to judge the ease of use from a Windows developer's<br>
perspective.<br>
<br>
I have received a few comments here and there that surround Windows installers.<br>
<br>
So if there is somebody who runs Rabbit on Windows who thinks an<br>
installer would be a good idea, may they step forward.<br>
<font color="#888888"></font></blockquote><div><br>I'm not a fan of Windows installers, because they usually put things into the registry. The uninstaller is supposed to remove these things, but too often they just don't work, leaving you with dozens or even hundreds of registry entries that you have to clean up somehow. Or, if you happen to change the drive letter on which the software is installed (by moving the software, for example), it breaks. Unless you use some third party tools.<br>
<br>One of the few times I would see a Windows installer as being useful in this case, MAYBE, is if you want to install RabbitMQ as a Windows service to start automatically when Windows starts, although how that plays with the Erlang VM needing to be running first, I am not sure. Maybe there could be some Windows code that starts the VM first. I'm sure there are better ways; I hardly touch Windows these days except when I am forced to.<br>
<br>The bottom line is that a self-extracting .exe archive (rather than a zip, which you could offer as well) with an expectation of a minimum running version of Erlang, plus some good command (batch) scripts and installation instructions would probably do the trick.<br>
<br>In terms of an earlier email about how to package the clients and server, I see it like this: repackage (and optionally refactor) the server into server-specific components and common components. Make the common components a separate Erlang app; ditto for client and server, and have the server and client depend on this app. Put in checks on both server and client side that they are running with a suitable version of the common app, and fail with a clear warning message if this is not the case. Make it easy for users to know which version of the common app the client or server depend on, preferably a simple script that invokes Erlang to delve into the guts and bring out the answer.<br>
<br>Offer a number of packaging options: client, server, and common; client and common; server and common; and common alone (for bug fixes and improvements).<br><br>My 2c worth.<br><br>Ed<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888"><br>
Ben<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br>
</div></div></blockquote></div><br>