[...]TCP/IP clients

Reinhard Doelz doelz at comp.bioz.unibas.ch
Thu Jan 26 13:42:40 EST 1995

ewan birney (birney at molbiol.ox.ac.uk) wrote:

: Tcl/tk is an interpreted language (yes?) which essentially makes
: command line calls to "embed" other programs: So don't you have to
: have both Tcl and your system running on the same box? I mean

yes - that is correct. 

: what some people are asking here is for a "client" to be running
: on a PC/mac and a "server" running on some mainframe with TCP/IP
: communicating things between them. Does Tcl allow you to do this...

no. As far as I know you must have a different program which does 
the client ip work. Tk/Tcl is only a local display environment. There 
are many,many extensions, though. Nevertheless, as it is an interpreted
language, it will only work if the interpreter is installed.  

: won't you still have to running X on your box for Tcl/tk to work
: with GCG  or port GCG to the PC (please correct me...)

no - maybe. See below. 


: I have no doubt that this has been done numerous times before, but
: what (as a programmer) I think would be nice is REAL low level
: control over the interface (you can't specify packing, button size
: anything)... you just ask what you need and you send it what you've
: got... Everything else is the client's problem. This gets close
: to HTML forms, except that an HTML form is *meant* to be a one
: shot thing, whereas I am asking for a real interface.

See the VIBRANT toolkit (Kahns et al., from the NCBI). It does perfectly
what you want. I remember that (admittedly, after some installation work)
having written the first application based on Jonathan's example after 
two hours. Have a look at the 'JAM' application - source code is on 
ftp://bioftp.unibas.ch/iarchive_data/survival/csource/jam.c and the 
look-and-feel binaries are in the corresponding directory of 
- apologies - there are some bugs in the software still but we plan 
to release the code in a refined version asap. 

: For graphics I was thinking along lines of Display PostScript??

Caution here! Display Postscript requires a Postscript-aware window system. 
As far as I know, this is not the case with the 'usual' programs but requires
specific binaries. JPEG as a colleague suggested is not loss-free. On harsh 
conditions (real good compression) line-mode graphics, uncompressed, are full 
of shadows and edges you didn't see in the original. GIF might be better 
in this view but you surely know about the recent licensing issue.  

I'm afraid this is getting the wrong group but we had discussions on 
esoteric newsgroups earlier :-) so why not discuss possible futures of 
Interfaces which also might affect client/server installations for WPI? 

For the display / network setup, let me draw a plot of the current WPI setup: 

     /----------------\                                 +-----------------+
     |     +--------+ |                                 |  HOST running   |
     |     | WPI win- |                                 |  x-client and   |
     |     | dows   | |      <==========================|  GCG and WPI    |
     |     +--------+ |                                 |                 |
     \----------------/       TCP/IP with X-Windows     +-----------------+
      X-server running

The PC does not know anything on GCG or WPI. Rather, it presents a X-Server 
and whether you send a xterm, a calculator, a whatever, does not matter. 

A WWW/http system runs like the following: 

     /----------------\                                 +-----------------+
     |+-------------+ |                                 |  HOST running   |
     || 'page' dis- | |                                 |  HTTP server    |
     ||play of FORMS| |      <==========================|  with CGI scripts
     |+-------------+ |                                 |  and W3 pages   |
     \----------------/       TCP/IP with HTTP          +-----------------+
      WWW browser run-                                                i
      ning, with a FORMS                                         +----i-----+
      interpreter                                                |GCG engine|
There is the PC or Mac running a W3 browser, talking to a HTTP server with 
the HTTP protocol (port 80). What you would need to look at in order to make a
page is a FORMS page, which is interpreted by the W3 browser with buttons 
and bells and whistles/. The returned http statement is worked on by a special 
program called by the httpd server, i.e. you interpret the resulting 
input you will need to write a program on the server side, which formats the 
request, and a 'page' which allows the browser to create the FORMS. To 
integrate GCG you will need to set up forms which allow the assembly of the
command line and spawn this as the 'processing engine. Then, this needs to 
be parsed again if it is non-presentable text (such as graphics).  Problems
here: input data - where? If on the central host with W3 server, security 
issue. If on PC/Mac client, additional program needed to xfer the data. 
And, consecutive requests? Require that if data are on PC/Mac a lot of 
communication is done. Alternative here: Hybrid servers (like we did it 
in the SRSWWW server (Thure Etzold), reference via WWW server on 
ftp://bioftp.unibas.ch/archive_data/www94paper_explode/paper.html). That 
is only good if the user has no input _files_, however. 

An ideal system surely uses our HASSLE system to communicate (well, honestly,
there is nothing better than that :-) but any client/server communication 
would serve the purpose in the beginning). However, this protocol will just 
allow to send data back and forth, and the client program will have access to 
local data and processing power. If there weren't something somewhere I 
wouldn't mention it but the idea is the following: 

     /----------------\                                 +-----------------+
     |+-------------+ |                           x===> |  HOST running   |
     ||client inter-| |                           |     |  HASSLE server  |
     ||pretation with |      x====================x     +-----------------+
     ||Tk/Tcl(interpr)|      |                          | application which
     |+-------------+ |      |                          | reads from stream
     || HASSLE comm.| | <====x                          | or HASSLE API   |
     \----------------/         TCP/IP with HASSLE      +-----------------+
The work is already four times the effort here. (1) you need the Tk/Tcl 
application, (2) you need a client program to feed it, (3) you need a 
host running the server and (4) you need to have an application interface
which allows the application to run via your selected client/server protocol.
The 'good thing' is that the TCP/IP application is under your control in a 
so-called STATEFUL communication, i.e. the remote application stays alive 
with respect to memory and data structures. This is not the case in WWW 
and related applications (see above). If you want to run a GCG application 
this way, you need a GCG-aware interface or at least an interpreter which 
can read all required data from a GCG-prepared stream off the socket, 
present the menu, and send the results back to the host. There, do a 
data request handling, and transfer the data back to the customer. 
HASSLE can do this and has done this for a long time already for specific 
applications which were fully GCG-aware (and, hence, are not running 
on PC and Macs, but watch out for HASSLE version 5 which is expected some 
time in summer!) 

You might, however, come back to the FORMS idea and send parametrized data 
rather than a stream dedicated for a single application. We do think that 
such a solution might possibly show up with the proposed enhancements for
W3, so we go the way of sending XDR'ed data structures instead (i.e. 
the currently unsupported YDATA statement in HASSLE). In contrast to the 
FORMS approach a dialogue of data structures will require more intelligence
at the client side. I.e., what you get in the end will be the requirement
to write an application package on the client side which is powerful enough 
to send data structures accross the net, and digest the incoming results 
sufficiently sophisticated to make data and menus from this. At this point, 
question might be whether the 'expect' statements in Tk/Tcl are powerful 
enough to cope or whether VIBRANT or VIBRANT-like stuff would be the better
way to go. Anyway, the client must be GCG aware to an extend which gets 
into dangerous grounds with respect to 'anonymous' usage. If we really 
had a suitable PC or Mac client the market were tremendous! -> so, who 
*pays* ?

You will probably be aware of the impact this development will have - the 
entire problematics of central vs. 'dull clients' reverts into intelligent
clients which are aware of authentication and security. Further, as the 
colleague from Italy mentioned, the prediction of the providers paying 
all and the clients running around the world finding 'some' server of the 
desired type is not a realistic way of going. At least not a desirable way.
Therefore, we have pushed our HASSLE development in the direction that the 
entire resource discovery, authentication, compression and encryption is 
already there.  As mentioned above, we do not currently support Macs and PC
platforms with HASSLE version 4.2, so there is no currently released software
which you can try out to see how the beast works. 


 R.Doelz         Klingelbergstr.70| Tel. x41 61 267 2247  Fax x41 61 267 2078|
 Biocomputing        CH 4056 Basel| electronic Mail    doelz at ubaclu.unibas.ch|
 Biozentrum der Universitaet Basel|-------------- Switzerland ---------------|
<a href=http://beta.embnet.unibas.ch/>EMBnet Switzerland:info at ch.embnet.org</a> 

More information about the Info-gcg mailing list

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