IUBio Biosequences .. Software .. Molbio soft .. Network News .. FTP

Different interface needed for V8.0 altogether:TCP/IP clients

Peter.DeRijk derijkp at reks.uia.ac.be
Wed Jan 25 06:33:01 EST 1995


ewan birney <birney at molbiol.ox.ac.uk> wrote:

    gquinn <gquinn at com1.med.usf.edu> wrote:
    >
    > Following the sudden resurgence in interest in X-windows emulators
    > since the release of GCG V8.0, I am prompted to add the following.
    
    [...delete...]
    > 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. I this way, data throughput would be enhanced
    > enormously, sequence data would be physically located on the machine
    > and the program could have a graphical interface even when used from
    > home or very remote locations, using the now-common SLIP or PPP
    > protocols or emulators (eg. TIA, Twinsock) and connecting via
    > a modem/telephone line. The people at NCBI have done exactly this
    > for Entrez very successfully, which runs superbly over a modem/PPP
    > modem/SLIP or modem/Twinsock. This is the obvious way forward.....
    > I wish I knew enough about programming to write the client software
    > myself, but my guess is that this would be a relatively easy thing for
    > someone to do, using the mechanism created for WPI.
    
    
    Ha... if you think its easy you do it :)
    
    Seriously, what you are asking for here is (at least for
    me) a programming nightmare. GCG are quite right to stay well
    clear of this. (unfortunately).

I believe it is possible, and even the way to go. I am currently writing
a project to create an easy to use evironment for sequence analysis. It
will run the interface locally, and should incorporate local as well as
remote services (which might include programs in GCG) seamlessly. I
would start on this project after I have finished my Phd. (but as
always, the execution of this project will depend on whether it will
get funding.)

This project will be based on The Tcl/Tk language. I have had very
good experiences using it to create an interface to my multiple
sequence editor DCSE. (for more information about tkDCSE and Tcl/Tk,
visit URL:  http://www-rrna.uia.ac.be/~peter/dcse
Tcl is a small but very flexible interpreted language. It is written in
C, and can very easily be extended. Tk is an extension to Tcl which
makes the creation of a windowed interface easy.  Complex interfaces
can be created with a few lines of code. Tcl is very portable and
already exists on UNIX, PC and Mac (and several others). Tk is
currently available for X-Windows, and a Windows port exists, although
it does not have the native Windows look-and- feel. TK is currently
being ported to Windows and Mac by the group of the author himself (John
Ousterhout). His ports will provide native look-and- feel on all
platforms.

The use of Tcl/Tk will offer several advantages, which should relieve
some of the (righttfull) concerns stated by doelz at comp.bioz.unibas.ch
(Reinhard Doelz):

    (1) The local feedback on the application is a problem which is impossible
    to solve without some 'intelligence'. ...

    (3) We (and 300 users at our site) appreciate GCG's homogenous
    (text) interface. ... 
    Concluding, I think that keeping a text interface which allows
    commandline input (like Don Gilbert pointed out) is the most versatile
    API GCG can provide for client/server environments. If the submitters
    of criticism don't like WPI, we as user community may suggest that we
    would like to see a Mac or PC _generic_ window which uses the same
    terminology and command files as WPI in order to lift the burden of
    generating windows on the host. We must be prepared, however, that
    suggesting this implies considerable changes, additions, modifications
    to the well-known environment, and there's a lot of training cost for
    all researchers there who have used GCG's command line or WPI already
    as supplied now.


Not only is Tcl/Tk a great language to create an interface. It is also
a reasonably featured programming language (solving the feedback problem)
and a great 'glue language': From Tcl it is easy to execute other
programs with any parameters (eg. GCG programs). This way the interface
can be created in Tcl/Tk, and from the data in the interface any command
can be composed and executed. There is no need to change anything to
their command-line interface. eg. in tkDCSE I have incorporated the
programs 'readseq' and 'Clustal V' seamlessly (except for the
acknowledgements ;-)), without changing anything in them.

    (2) PC and Mac applications talk _very_ different tongues. Apple events 
    are easy to program for a Mac programmer, but certainly don 't agree well 
    in source code with the corresponding Windows code. 

It will be easily portable to the mainstraim platforms, when the ports
are finished.

    Therefore, I would consider TCP/IP to be the most generic 
    protocol as understood by most reasonable operating systems. The more 
    fancy you want to become the more off-mainstream your development will 
    be. 

There already exist extensions to Tcl which will provide an easy access
to TCP/IP, etc.

A very important property of Tcl for this project is its interpreted
nature. In Tcl any program, procedure or range of commands is
represented as a string that can be handled as data, ie. changed,
transmitted, and executed at run-time. This property makes it possible
to send a range of commands (eg. a new function, the commands needed to
run a utility, etc.) via TCP/IP to a Tcl interpreter on another
machine, where they can be executed directly.

In my vision, the interface and even most of the tools would run
locally in a Tcl/Tk interface. For some analyses, database searches,
etc., a set of commands and data can be executed in an interpreter
running on another machine (server). Naturarly, other services can be
accessed as well, by executing their programs.

If other people are interested in this project, have suggestions or
want to cooporate, I can be reached at derijkp at reks.uia.ac.be.

Regards,

Peter De Rijk



More information about the Info-gcg mailing list

Send comments to us at biosci-help [At] net.bio.net