Client/Server

[acheslow]

It would be nice for the HouseBot GUI and backend server to be a separate client and server so that I could run the client on my laptop to configure and monitor the server running on my HTPC. Ideally I would like to start up a windows service on the HTPC and then have all other interaction be through a client on my laptop (similar to the Microsoft Management Console that can connect to and manage another PC on the network).



Device replication doesn't quite allow for this, nor does running HouseBot from a shared network drive. I can pretty much edit themes on my laptop by running the full HouseBot application but it is looking for interfaces and devices on my laptop instead of on the server.



Thanks!

Alan

[ScottBot]

I know this would be nice, and it is on the list.



I know at first thought it seems easy to separate the configuration UI from the database, but it really is a fairly big (and potentially de-stabilizing) project. The big issues will be sharing of data and 2-way notification between the single DB/Server and all of the remote config UI's. I don't really want the overhead of using a 3rd party messaging solution, so I'll probably have to write my own.



It's actually an interesting project for me, but I've just had so many other really nasty and necessary features ahead of it. Maybe once 2.0 settles I'll have some time to look at it.

[acheslow]

Thanks, I understand. Here's another idea...



After playing around a little more I found that I could almost get the same effect by doing the following:

1. Install HouseBot on the server as normal
2. Install a separate HouseBot instance on my laptop's local drive
3. Keep the HKEY_LOCAL_MACHINE\SOFTWARE\CEBotics\HouseBot\General Settings key pointing to the DB on my laptop (I had changed this to point to the server before)
4. Change the HKEY_LOCAL_MACHINE\SOFTWARE\CEBotics\HouseBot\Root Application Directory key to point to the network directory where the server is installed
5. Manually create device replication objects on the laptop database to match each of the devices on the server

This will allow me to run HouseBot on my laptop while accessing the devices and themes from the server. Using this approach,then, what would be nice would be the following:

• Ability to automatically replicate all devices from one server to another instead of manually creating each one
• Mode replication
• Task replication

Again I say these things would be nice because HouseBot is already an excellent program and this would just be icing on the cake.



Thanks!

[Circe640]

Muck as I hate to say it, from my perspective of what M$ is going to support in the future, Writing for an NT service is going to be a wasted effort. M$ has been making that very clear whether we like it or not. The only fully supported environment for the future is .NET They have pretty much forced every major development environment, including the company I work for to move development to that base.

[MediaStorm]

Muck as I hate to say it, from my perspective of what M$ is going to support in the future, Writing for an NT service is going to be a wasted effort. M$ has been making that very clear whether we like it or not. The only fully supported environment for the future is .NET They have pretty much forced every major development environment, including the company I work for to move development to that base.

I think you are confused about the technology names in this regard. NT services are not going away anytime soon without a complete rewrite of the entire OS. .NET itself runs as an NT service for session management and etc.



It is absolutely possible to develop an NT service application using .NET quite easily.



The ability to run HouseBot as an NT service would NOT be a wasted effort whatsoever. Windows 2003 Server (aka .NET server) is in fact Windows NT 6.



There were two different angles to the whole .NET thrust. One is the actual IDE and framework and the other is the 'platform' itself. The .NET metaphor was dropped from the server naming as it was too confusing to the general population to understand what context .NET was talking about at any given moment. That's why Windows 2003 Server was renamed and the whole .NET naming was dropped from all servers.



And, for what it is worth VB6 and C++ are still widely used now and will be into the future for quite some time. Just because M$ is phasing out support for these products doesn't mean that they are dead by any means. Nearly all M$ applications get the largest amount of support via third party providers anyway and that support will be around as long as someone is willing to pay for it.