I agree with this: client software running on local computers
for user interface aspects, and server software on central/distributed
computers for the computational load, data management, etc., is the way
good biocomputing software should be designed.
This philosophy is what prompted me to start a Mac Hypercard stack
for a local GCG client a while back. It was never finished due to
lack of monentary/time support, but it would not have been a programming
problem to finish.
Currently the NCBI Toolkit offers a public-domain set of tools that
any company or group can use to build client/server software that runs
on all the common computer systems. This would make a good foundation
for any client/server work.
HTML and Gopher Internet browser software are options for simple
client/server functions. I have doubts it will be sufficient
for complex biocomputing client/server needs. That is one reason that
I've continued to develop an expanded, OOP-framework based, Internet
client. Such software can be wedded with biocomputing functions (like
a sequence editor) to make a good client program for the user interface
aspects of sequence analysis. Then link it with tcp methods founded
on, e.g., Internet Gopher or http protocols, that tie to server routines to
do the computationally intensive analyses, and you have, I hope, a good
method for the average biologist to do sequence analyses.
XWindows is not a panacea for replacing good client/server methods.
It is slow, bulky, awkward to use unless you are running the X client/servers
on the same fast host (try running X over a modem, then compare
that to running Gopher or even Mosaic over a modem). The average
X program is way behind current Mac (or even MSWin) software in usability.
A few years ago I made a large effort to get XWindow-capable computers
and software for our biology department. I think I can count on the
fingers of one hand the number of students that now use XWindow software,
unless they are sitting in front of a local Unix box where they must use it.
In article <3frk1c$14e7 at tequesta.gate.net> gquinn <gquinn at com1.med.usf.edu> writes:
>What am suggesting (in a long-winded fashion!) is that GCG should
>NOT be concentrating on honing their X-interface to perfection,
>but rather developing TCP/IP clients that would run on local Macs
>and PC's, and would connect to a GCG daemon running on the server
>that would handle program requests, submit them, and send them back
>the remote PC/Mac.
As long as GCG keeps the command line interface to their software, others
can build the better client/server methods to use it.
-- d.gilbert--biocomputing--indiana u--bloomington--gilbertd at bio.indiana.edu