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 +-----------------+
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
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
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>