-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Graham Fawcett wrote: | | Personally, I would go for the separate-process model, for a couple of | reasons: | | * it's cross-platform: for example, Win32 can't fork. This may not | be a requirement for your app, of course. | * it's distributable. Once you're message-passing between | independent processes, it's a small jump to passing those messages | across a network. Imagine a Beowulf cluster of those... ;-) | * improves availablity and reuse: it's easy to add other types of | clients which can request the same type of task. You're building | components and wiring them together, instead of building | monolithic apps. | * it really forces a clean separation between the client and the | business process. Maybe it's just me, but I like to have buffers | like that, to prevent me from creating dependencies where they | don't belong. | | You've got lots of choices for interprocess communication; I'd go for | something that, at its basic level, is inet-socket based and | language-neutral, again for cross-platform and distributability: xmlrpc, | maybe, or tuple spaces if you go in for that kind of thing. (I run a | little Quixote-based tuple-space server that works well enough, and is | very easy to use from a developer standpoint.) Or just drop job-files in | an "in" directory and look for results in an "out" directory... | | A drawback is that you have an extra dependency for your app: you have | to keep the back-end application running independently of your | Quixote/Apache processes. You may also need a means of ensuring that the | back-end app is running, and a way to kickstart it if it's not. They are | surmountable issues, but it's a step away from the "works out of the | box" simplicity of a monolithic app. | | Are you "gonna need it?" Maybe this is a whole lot of overkill for a | simple application. Personally, I've not been disappointed by | service-oriented design -- there are some real benefits to be reaped -- | but it has to feel right to you, and seem logical for your application. | | Just my two cents, | | -- Graham | Thanks to everyone. I'm convinced on the separate-process model for a couple of reasons. First these arguments above make alot of sense and are very compelling to me. I had a thought that why make the user keep coming back to find out if its ready, have the process notify the user - the second model makes this trivial. Second the comments about waitpid and what have you made me fully realize I don't understand enough about spawning/forking processes. If i can't explain what's going on I don't feel confident going down that path. (pointers to spawning/forking still gratefully accepted) thanks again! - -- Tom Jenkins devIS - Development Infostructure http://www.devis.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0-nr2 (Windows XP) Comment: Using GnuPG with MultiZilla - http://enigmail.mozdev.org iD8DBQFAq7hJV7Yk9/McDYURAh3/AKCU/iqh9VGtjT925MVyeWgSJroA5wCgx+xU IWBQT9In2v0v87z+Jxt18ok= =J7W1 -----END PGP SIGNATURE-----