Re: porting curses driven to gui application
Jens.Toerring_at_physik.fu-berlin.de
Date: 09/12/04
- Next message: Theo Harlauch: "Re: porting curses driven to gui application"
- Previous message: Bulent Murtezaoglu: "Re: Xah Lee's Unixism"
- In reply to: Theo Harlauch: "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 15:06:34 GMT
Theo Harlauch <t.harlauch@freenet.de> wrote:
> I'd like to port an application of mine which is currently just curses
> driven to a guish one. For now, all users ssh(normal login and password)
> to a linux server and start the app by typing its name on the prompt. So
> they are all starting the same executable on the server. So I don't have
> to bother with any remote database connections.
> If I'm gonna change to a gui app now (e.g. qt), I'm not sure how to
> handle database requests. For security reasons I shouldn't open the
> database (Informix Online) to listen on any network interfaces (except
> lo). Do I really have to write a sophisticated client-server application
> then? Are there any other solutions? Maybe anyone here on this ng has
> done such porting yet?
It looks a bit as if you're mixing up a few things here. Having a
GUI or not has nothing at all to do with network related stuff or
remote database connections. It seems as if you want to do a lot
more than just replace the curses interface by a GUI.
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.
Things get quite a bit more complicated if the external machines
don't have a X server (e.g. because they are just running Windows
without much more installed than ssh). Then you will have to
resort to some kind of client/server architecture and you will
have to decide what of the functionality goes into the client
and what into the server,
One solution could be to use web pages for the user interface. The
user enters some data into a page created by the server, the data
get send to the server, which then evaluates them, dealing with
the database as necessary, and creates a new page according to what
the user send. For that you will need some kind of HTTP server on
the server plus some set of e.g. CGI programs (or some scripts in
a language the HTTP server is able to interpret) that interact with
the database. In that case the database doesn't need any external
connections, it's driven by the CGI scripts running on the server.
Nothing needs to be installed on the client side (except a browser,
of course).
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.
Finally, you can write a program, running on the client side, that
does everything itself, including the interaction with the database
on the server side. In that case you would have to allow external
connections to the database.
Regards, Jens
-- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de
- Next message: Theo Harlauch: "Re: porting curses driven to gui application"
- Previous message: Bulent Murtezaoglu: "Re: Xah Lee's Unixism"
- In reply to: Theo Harlauch: "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
|
