IUBio

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

ewan birney birney at molbiol.ox.ac.uk
Fri Jan 27 08:12:51 EST 1995


derijkp at reks.uia.ac.be (Peter.DeRijk) wrote:




I have deliberated somewhat on whether to keep posting on
this thread, which interests me alot, to bionet.software.gcg
Maybe it should to moved to somewhere else (? Like where) or
just take to straight email... If people are getting bored/
annoyed, just post/set up a kill file :)


The thread started off with a discussion about the GCG X
interface new in GCG8, and how much success running this
from a Mac/PC X terminal. I think most people want to have
a PC/Mac client "talking" to a GCG server. You want native
PC/Mac feel and as low as possible network communications.
As most people have realised, this is not what you get when
running X, which is perhaps better thought of as a generic
windowing system for UNIX (VMS) systems.

So how do you get a client<->server paragdim to work with
a package like GCG. The best way would be if there were some
widely avaible tools which handled all the communication 
so that programmers in particular didn't have to worry about
TCP/IP. In addition for windowing systems, Mac, PCs and X
are *very* different, so ideally for the programmer you want
some "higher" language that you use with this being interpreted
run-time (like Tcl/tk) or compile time (like Vibrant) as 
the correct windowing system.

HASSLE is a series of programs that deals with TCP/IP and many
other WAN issues transparently to the user: ideal perhaps for
this system?

Looking from the other end, a system like http: with HTML follows
a similar but more restrictive paradigm: The client sends off
to the server some requests, and the server just replies. Currently
the clients have been restricted in not allowing client side
files to be shipped in (hence those horrible cut+paste forms
for sequence servers), but I think that will be allowed.

But in particular there are two ideas firmly rooted in http:
a) there are no "sessions" on the server ideally. The server
should just be supplying information, either simply a file or
a back-end program (eg search engine).
b) The client interprets the sent files with no help from the
server (eg .gif will bring up a viewer, .ps ghostscript etc).

Although both ideas have been corrupted in the WWW, they are
still I think quite central to the WWW, and one of the reasons
for its success because it allows separate development of clients
and servers.


So although I think we (... someone, not me :) ) could put 
together a client<->server GCG thing, it would a) be a nightmare
to code b) probably be specific for one windowing enviroment...

So... use Tcl or Vibrant for the windowing and HASSEL for
transport and... hey presto. But again I think this is a large
project. Anyone who wants to do this should think REAL hard about
how it should be written.

I think it would be better to take http:/html as are starting point
and work upwards keeping in mind two important points.

a) The client (or customer when we start talking HASSLE) is
responsible for the presentation. If someone wants to write a 
client in VIBRANT.. TCl, or anything, then great...but it is
responsible for the prompts and the display

b) The server/provider only sends the data (we have to agree on
data... I would say ASN.1 except I can't understand that). The
server HAS to be savvy enough to keep checking the client/customer
is still out there (occassionly).

(this is sort of what I meant by a Logical User Interface)

The big difference with http is that you should be running
a session on the provider from your customer. (Hassle redefines
client as customer and server as provider because they no
longer take on the formal client<->server outlook).

I don't think we should aim for "interrupted" session control
for long durations (eg hours) - that is better done through batch
systems, though I think a beauty of hassel is that it can "sleep"
the transmission...

And then we have to agree on protocols so that everyone does
something that is compatible with someone else, and allows Client
and Servers to evolve separately.


Ha... I hope that was interesting (I'm finding this discussion
interesting).

Now... 

a) Doesn't hassel have to have a daemon running each end to deal
with the sort of indeterminant timed "are you out there" beeps?
How does this work with a PC/Mac that doesnt't really have the
sort of kernel control you are asking for (eg... people switch
them off)?


b) Isn't better to leave off windowing (which is *TERRIBLY* important
for the user, but a little side show for the development) for
the moment... concentrate on how to get a free-form session to
run across a WAN?


c) If we are going to do this, can we get together to agree on
how things should develop??? The trouble about everyone working
independantly is that then you find that one program is based
around a different paradigm from the one you want it to talk to
and hence you get some really *horrible* hacks to get around
things. Look at WWW forms that attempt to act like sessions by
having some spurious number appended to the form...


ewan

my 0.02$
  



More information about the Info-gcg mailing list

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