|There's more than one way to do things|
Desktop Application vs http://localhostby perlmonkey2 (Beadle)
|on Dec 14, 2006 at 22:35 UTC||Need Help??|
perlmonkey2 has asked for the
wisdom of the Perl Monks concerning the following question:
I've been tasked with implementing an expert system and the only other requirements were that "it can run on a laptop". The people I work with know ~0 about software development and just want to be able to use the expert system on their Win32 laptops.
But the expert system's ability to provide results scales directly with processing power/memory. So my idea is instead of giving them a desktop application, I'll give them a web application that talks to either a local apache, or a perl http server, which in turn talks to a POE server (implementing the expert system) via SOAP. This way, once the application is finished, the pieces can be broken up to different machines as needed/desired.
The initial install would install the POE server, and Perl http server and a Perl script to launch everything. When the Perl script was launched, it would make sure the POE server and HTTP server were started, then tell MS to start the default web browser to localhost:appport.
But when they decide that a single job takes an hour and that running multiple jobs is the way to go, and then realize that running a hundred multiple jobs is "da' bomb", they can offload the POE server to a massive piece of hardware and still go along their merry way with only a minor change to the config file.
Can anyone think why the minor additions in the communications protocol would not make it worth while vs a simple desktop applcation? Security? Complexity? Fault tolerance? Additional overhead of resources?
And if you are asking why the webserver and the additional SOAP server, I want to develop the GUI as a web app but leave the option for a .NET or JAVA front end.