RE: Universal admin frontend - Mailing list pgsql-hackers
From | Pedro Abelleira Seco |
---|---|
Subject | RE: Universal admin frontend |
Date | |
Msg-id | 20010621120311.34833.qmail@web9507.mail.yahoo.com Whole thread Raw |
In response to | Universal admin frontend (Pedro Abelleira Seco <pedroabelleira@yahoo.es>) |
List | pgsql-hackers |
>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
pgsql-hackers by date: