>For an admin tool you might want to display OS info ,
>server load,
>database file sizes, logfile viewing etc. 
>I have been working on such a tool for my own use , (
>GTK+ based front
>end) and decided that a client / server model would
be >the most useful
>approach. I was probably going to write a separate
>daemon rather than
>integrate new stuff into the backend.

I agree. In fact one important thing is to be able to
edit the configuration of Postgres (of the different
servers) from the app. Administration should include
configuration. And backups, too (with a register of
them).
I also think that the separate daemon would be
necessary (you should be able to start/stop/restart
servers).
In a first aproximation one could write a totally
independent daemon able to manage the tasks not
accesible by the standard interface. I mean, no table,
user, ... management; this is solved. But it's clear
that it would be easier (and more reliable,
mantainable, elegant) not to have to duplicate things
like the config file parsing. One could pick code from
Postgres itself, but a copy/paste strategy is bad in
the long run (not so long, in fact).
If one could access some things of the Postgres
engine, it would be easy to have the daemon. But you
should compile such code in the postgres build
process, or have a API to ask Postgres this kind of
things. Both aproaches should have aproval/support by
the developers.
Of course at the start one can develop this as a
patch/addon to the Postgres code, but in the long run
it should be in the core distribution (with a option,
sure) for use by all the admin tools.
The only hard part is the communication protocol. It
have to be secure. Secure by design, so simple. And
usable for many diferent languages. But I think that,
for a start, one should abstract the communication
protocol in a interface to help us to concentrate in
the general problem, and to plug after a communication
lib.
Because one cannot simply start coding some that has
no one use case, my idea is to develop a Gui tool,
concentrating it in the aspects _not_ covered by other
tools (pgacces, phppgadmin, pgAdmin, ...) and with a
rough support for the usual aspects (user, tables
management, sql querys, ...) to have a good prototype
in wich experiment what is really needed in the
backend. Once this done you can mature the tool
independently. The other configuration tools can
extend to use the new capabilities if they want.

Pedro

_______________________________________________________________
Do You Yahoo!?
Yahoo! Messenger: Comunicaciï¿½n instantï¿½nea gratis con tu gente -
http://messenger.yahoo.es

Thu, 21 Jun 2001 14:03:11 +0200 (CEST)
=?iso-8859-1?q?Pedro=20Abelleira=20Seco?= <pedroabelleira@yahoo.es>
RE: Universal admin frontend