web interface to c program running on different server

Cameron Laird claird at starbase.neosoft.com
Tue Jul 17 11:48:31 EDT 2001


In article <mailman.995377053.13982.python-list at python.org>,
=?iso-8859-1?q?Fran=E7ois?= Pinard <pinard at iro.umontreal.ca> wrote:
			.
			.
			.
>Not so long ago, I had something to do which was (probably) similar.
>We had a rather complex application in C that was meant to be used in
>batch mode on massive input, delivering massive output.  We wanted to
>include it in a Web application for processing one set of input at a time.
			.
		[plenty more detail]
			.
			.
>Finally, I opted for something very simple, clean, and quick to implement.
That's sure my favorite.
			.
			.
			.
I very much like Fran=E7ois's description.  These "case
studies" are valuable. 

He raises a couple of points that are special concerns
of mine.  Small, simple, reliable parts are, of course,
a great idea.  I'll add that it's absolutely fine to
build-in "extra" capabilities--self-diagnosis, network-
ing savvy, ...--to an existing or planned application.
Real-life experience shows that these can frequently
*simplify* a project.  Even though there might be no
requirement in an original specification for Web access,
if it makes development easier enough (by facilitating
testing, for example), implement it, and keep it "in
reserve".

Any day now, it'll be natural to design more and more
of such applications in terms of WS (Web Services as a
standard--XML-RPC and such), and then use common tools
(including the already-well-endowed Zope) to provide a
human-viewable Web face over the WS API.  Among other
advantages, this will provide another interface boundary
that developers presumably know how to engineer reliably.

Nice work, Fran=E7ois.
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html



More information about the Python-list mailing list