Re: porting curses driven to gui application
Jens.Toerring_at_physik.fu-berlin.de
Date: 09/12/04
- Next message: Rich Teer: "Re: ANN: New UNIX programming book"
- Previous message: Ken Mandelberg: "Re: ANN: New UNIX programming book"
- In reply to: Theo Harlauch: "Re: porting curses driven to gui application"
- Next in thread: Theo Harlauch: "Re: porting curses driven to gui application"
- Reply: Theo Harlauch: "Re: porting curses driven to gui application"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 12 Sep 2004 19:26:59 GMT
Theo Harlauch <t.harlauch@freenet.de> wrote:
> Jens.Toerring@physik.fu-berlin.de wrote:
>> When you write that the users log in via ssh it indicates that they
>> are not sitting at a terminal connected to the machine where the
>> application is running but connect from external machines and work
>> on the machine they log in from. As long as the other machine a
>> user is coming from has a X server running (and ssh is configured
>> to allow X forwarding) you don't need to change anything about your
>> application beside replacing the curses interface by the GUI -
>> everything else works as before, the GUI can be easily shown on
>> the external users screen via X - the users still log in via ssh
>> and start the application by typing its name at the prompt, only
>> that they now get a GUI to interact with. Your only headache will
>> probably be the time it takes to display and update the GUI on the
>> external machines, but that won't be that problematic as long as
>> everything runs on the same LAN or over some other fast network
>> connection.
> In fact, most of the users are running PuTTY on their windows 2000
> clients, some of them are using xterm on linux.
> Well, what about installing a local X server on the windows clients like
> Cygwin/X [1]? I haven't seen Cygwin/X in action yet, though. So there
> might be some pitfalls too since it is just a port of the X Window System.
I can't say since I don't use Windows. But in principle I don't see
any unsurmountable problems, at least it would be worth trying since
if it works it would probably involve the least amount of work by far.
>> Next solution would be to have a program running on the clients
>> machine that shows the GUI and connects to a server process
>> running on the machine where the database is also running. You
>> have to develop some kind of protocol how data to be put into
>> the database or retrieved from it are to be exchanged between the
>> server and the client on the user side. Part of the original
>> functionality (mainly the user interaction) now is on the client
>> side while on the server the interaction with the database is
>> done. What exactly of the functionality you put into the client
>> and what in the server is up to you. It could go from just sending
>> some information about what the user just entered into the GUI to
>> the server and reacting to what the server then says to do (so most
>> of the work is done by the server side) to sending complete database
>> commands to the server, which it just passes on to the database, and
>> having the results of queries returned to the client (thus having
>> nearly all of the functionality on the client side). Still, no
>> external connections to the database are necessary.
> This looks like a possible solution. Are there any standards floating
> around for writing such kind of protocols? I guess we are talking about
> sockets and TCP here...
TCP and sockets will of course be at the bottom of it. Typically,
on the server side you create a socket using socket(2), then call
bind(2) and listen(2) on it before waiting for incoming connections,
to which the server reacts with accept(2), possibly after spawning
a new process with fork(2) to deal with the new client. On the
client side under UNIX you would use socket(2) and then connect(2)
- under Windows it's probably similar. If you really want to write
something like that it's probably a good idea to get a good book
about the subject, W. R. Stevens "UNIX Network Programming", Vol. I,
is one I can recommend - but I don't know how much of what you learn
from that is also applicable to Windows.
On top of that you need some kind of home-grown protocol to determine
in which way client and server react to messages from the other side.
How this looks like depends a lot on which of the functionality goes
into the server and what into the the client. Let's take as an example
the case where the client sends complete database command, which the
server passes on to the database and, if necessary, has to return the
results of a query. Then a very simple protocol would be to have the
client simply send a string with the database command. Returning the
reply is a bit more tricky since you don't necessarily know in advance
how many data items will get returned for the query, so the server may
have to count them and send their number to the client before sending
all items e.g. one by one (probably after converting them to ASCII).
And you must be able to pass back error messages if the request failed.
Another thing that will be "interesting" is user authentication and,
if necessary, encryption of what's going over the network - you don't
have the ssh protocol doing all this for you transparently, so you
perhaps will have to take a good look at SSL or something similar -
but I have not much experience with that.
Regards, Jens
-- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de
- Next message: Rich Teer: "Re: ANN: New UNIX programming book"
- Previous message: Ken Mandelberg: "Re: ANN: New UNIX programming book"
- In reply to: Theo Harlauch: "Re: porting curses driven to gui application"
- Next in thread: Theo Harlauch: "Re: porting curses driven to gui application"
- Reply: Theo Harlauch: "Re: porting curses driven to gui application"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
