Girder as a service

[tlum]

Any thoughts on creating a "service" version of Girder? After all, Girder is a service... and I run it on a real server... and srvinstw/servany is a real hack and does not really work since Girder seems to shutdown if you log out of the console. Have to use the srvinstw/servany hack for now and just never log into the box without rebooting on the way out, but would like a cleaner solution.

-Ted-

[cjean]

Yes you have a kind of a Girder service. In fact its a runtime application located in the girder directory. The name of it is grunt.exe. Its like having Girder running without the interface. You can launch this service from the Girder start-up options and click on Runtime.

Hope this answer your question.

Charles

[tlum]

Yes, Grunt is a lighter version of Girder. But no, it IS NOT a service. And, no, it does not solve the original problem which is it won't stay running as a service if you log in to the console and then log out... every time I'm force to log in for maintenance I have to restart the box, not logout.

Would suggest to Promixis, from an architecture perspective, that core code moves out of Girder and into a Windows service. Then Girder UI code calls the core service API. This way the service is always there running and you can start and stop the UI as needed.

-Ted-

[Ron]

We have looked at this several times, but sadly desktop interaction limitation of services keeps us from fully moving to a service based platform.

[tlum]

Exactly! They are two entirely different audiences. The one camp (me for one) that uses Girder on a dedicated server that does network messaging and mainly RS-232 control of other devices. Then there is the other camp that uses Girder underneath Windows applications for status and control. The former should come up with the server O/S and rarely ever sees an interactive session (OK, once a month on patch Tuesdays). The latter doesn’t need to be there until the user logs in and has some applications to run on top of it. And, yes, its not that back and white, there is some overlap, but you get the point.

Hence the idea of splitting the core functionality away from the UI and session based functionality. In a true server service environment there is no keyboard or mouse to hook, no sessions going, no applications running. Basically all you have is timers and comms. So let the core run as a service and deal with timers and comms. Then if user sessions are required a copy of Girder.exe runs which hooks the Windows session as it does today, only it has no core, the core in reached through an API to the background service. It’s sort of a modular approach where one or more .exe’s can extend the core service.

But that’s a lot of work to be sure. For now I would be happy if when I run grunt.exe as a service - which I am doing today through a bit of a hack – if it would not terminate when a user logs out of the console AND it provides logging to disk as in unattended operations there MUST be a means to monitor background services.

-Ted-

[Ron]

Actually the UI is totally separate from the core (as can be seen by the grunt.exe application). However, the code I talk about is the UI manipulation code, where Girder programatically interacts with other apps.

I guess we could split the core in two items,...