Create an installation program

[wishi]

Provide an installer, with Explorer integration and tray icon.

I can start on a Windows installer using NSIS we should get a list going for
what the installer should do:

Create/Copy Program Files
Register Service
Add Icons
etc...

On Sat, May 28, 2011 at 4:59 AM, wishi <
reply@reply.github.com>wrote:

Provide an installer, with Explorer integration and tray icon.

Reply to this email directly or view it on GitHub:
#4

[hach-que]

Use Inno Setup for the installation system; it generates a much more native Windows installation experience than NSIS.

There isn't much need for explorer integration or a tray icon for that matter; I'm thinking it'd be better if we integrated it into the control panel as an applet to make it a more integrated component within Windows.

[teh-hippo]

What's our perspective on associating with TermKit for Unix & for Mac? Does the installer affect that at all?

I'd be in favour of either NSIS or Inno, but I believe it should be one that has some element of portability... I mean we have to think ahead :)

[hach-que]

The installer only needs to be for Windows; Mac and Linux both have their own application installation systems (e.g. for Debian there's .deb, for RPM-based there's .rpm, for Mac there's .app).

[wishi]

Hi everyone,

why would you integrate TermKit into ControlPanel? For administrative tasks it doesn't provide anything.

• I think the most interesting part here is simplicity: installer setup-phase, TermKit service needs to be autostarted with the TermKit frontend. Still, I do not suggest an autostart-Windows system service. At least not at this point. Also necessary is to keep the folder structure, because I saw some hardcoded paths in the source. Not sure how to patch that at the moment.

Best,
Marius

[hach-que]

Because the TermKit service will be constantly running in the background, rather than being started along with the client; this allows us in future to easily add support for remote connections. If we don't do it this way now, and instead embed the server within the client, then when we need to support remote connections, we'd have to rewrite the whole system for executing the Node.js server.

By designing it to run the Node.js server permanently from the outset, it means that later on all we need to do is change the bound port from localhost:2222 to :2222.

So, since it's running all of the time, there needs to be an easy area to configure the service side of things (this will be more important with remote connections when you want to define what users and computers can connect).

[wishi]

So, any progress... for the auto-updater stuff we should also coordinate our efforts here.

[hach-que]

I've been really busy lately with university and work commitments, so I haven't had a chance to do much outside work on the Node.js implementation on .NET.

I should be free again in about 1-2 weeks time.