Desktop Application vs http://localhost

[perlmonkey2]

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.

[webfiend]

Sounds like you've got a lot of fun and nifty ideas, but a lot of them are handwavy "This'll make things all better when X happens or when I decide to do Y." Unfortunately, X doesn't happen nearly often enough. Instead Z, Q, and π happen, and all the careful planning and hard work you spent on X morph into another learning experience. And you may never even get the chance to try Y.

Start figuring out the miminum that this thing needs to do, other than the irritatingly vague "it can run on a laptop" (Bosses, don't you just love them)

Worry about the multiple-interface SOAP frontend later. First just write the app they asked for, if that's possible :)

[Cabrion]

You'll want to make sure they realize that running on a laptop this way, will mean running on a laptop with a connection back to the SOAP server. It's not going to work if they take it into a basement that has no wireless coverage.

[jbert]

Why split it out over two network protocols?

If you are going write a SOAP layer you don't need to go over HTTP too to get the possibility of back-end-on-big-iron.

The GUI front-end needn't be .NET or Java. If you're happiest in perl, you could do a perl/Gtk2 (or perl/WxWindows or even perl/Tk) front-end. The first two options at least look pretty 'native' on Windows.

But if you're happiest doing GUI work as web pages, then you could do what you say. But then you could leave out the SOAP entirely. Just write a web app as you described.

Put a nice, clean abstraction layer in your code at that boundary and it will be fairly straightforward to SOAP-ify it later. And you'll even get to re-use your interface unit tests so that you know it's all working ;-)

So...my first choice might be zero network protocols (native client, with code on board). Do a decent model/view/controller split and then you'll have the option of putting in another controller/view for a web interface, talking to the same local model. Or the option of splitting off the backend over SOAP. But I'm not sure you need both.

[perlmonkey2]

Thanks everyone for the great advice. I've been going over what you all said with some friends and the MVC single app making direct calls to the libs looks to be the best solution.

I'm the only developer at this place so it really helps to have people sanity checking my ideas. Thanks!