Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Desktop Application vs http://localhost

by perlmonkey2 (Beadle)
on Dec 14, 2006 at 22:35 UTC ( #589922=perlquestion: print w/replies, xml ) 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.

  • Comment on Desktop Application vs http://localhost

Replies are listed 'Best First'.
Re: Desktop Application vs http://localhost
by webfiend (Vicar) on Dec 14, 2006 at 23:33 UTC

    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 :)

Re: Desktop Application vs http://localhost
by Cabrion (Friar) on Dec 15, 2006 at 00:43 UTC
    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.
Re: Desktop Application vs http://localhost
by jbert (Priest) on Dec 15, 2006 at 10:58 UTC
    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 ;-) 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.

      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!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://589922]
Approved by Joost
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2018-04-23 11:58 GMT
Find Nodes?
    Voting Booth?