>Hello!

>Why not go back to the roots of postgres?

>PostgreSQL is written completely in C. The
development community has
>shown that it is
>possible to write efficient code for different
>platforms with pure C.

>The administration task can be separated in 2
different tasks:
>A server (in C) which is really doing the
administrative work.
>A client programm written in what so ever (C + X11,
Java, Perl, TCL/Tk, 
>....) which performs the user interface.

I think you are totally right.

>I know that this a not the easiest way to do the job
but the most
>flexible (in my opinion).

In fact I believe that it is also the easiest.

Pedro

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

Thu, 21 Jun 2001 10:17:30 +0200 (CEST)
=?iso-8859-1?q?Pedro=20Abelleira=20Seco?= <pedroabelleira@yahoo.es>
RE: Universal admin frontend
> >PostgreSQL is written completely in C. The development community
> >has shown that it is
[snip]
> >The administration task can be separated in 2 different tasks:
[snip]

Isn't this essentially the split between postmaster/workers and a client?
i.e. I don't know how much value is added by introducing another
communication protocol when JDBC would work fine. From my understanding of
the users API you can handle pretty much everything other than pg_dump. Eg
CREATE USER, CREATE DATABASE etc can all be issued from a client using
standard PostgreSQL SQL.

I'd have to cast my vote on the Java frontend.

Cheers,

Mark Pritchard


Thu, 21 Jun 2001 19:23:09 +1000
"Mark Pritchard" <mark@tangent.net.au>
RE: Universal admin frontend
On 21 Jun 2001 19:23:09 +1000, Mark Pritchard wrote:
> > >PostgreSQL is written completely in C. The development community
> > >has shown that it is
> [snip]
> > >The administration task can be separated in 2 different tasks:
> [snip]
> 
> Isn't this essentially the split between postmaster/workers and a client?
> i.e. I don't know how much value is added by introducing another
> communication protocol when JDBC would work fine. From my understanding of
> the users API you can handle pretty much everything other than pg_dump. Eg
> CREATE USER, CREATE DATABASE etc can all be issued from a client using
> standard PostgreSQL SQL.
> 
> I'd have to cast my vote on the Java frontend.
> 
> Cheers,
> 
> Mark Pritchard
> 



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.


-- 
Colin M Strickland  perl -e'print "\n",map{chr(ord()-3)}(reverse split 
             //,"\015%vhlwlqxpprF#ir#uhzrS#hkw#jqlvvhqudK%#\015\015nx".
"1rf1wilv1zzz22=swwk###369<#84<#:44#77.={di##339<#84<#:44#77.=ohw\015]".
"K9#4VE#/ORWVLUE#/whhuwV#dlurwflY#334#/wilV\015uhsrohyhG#ehZ#urlqhV");'

21 Jun 2001 10:55:59 +0100
Colin Strickland <cms@sift.co.uk>
RE: Universal admin frontend
Colin Strickland wrote:
> 
> On 21 Jun 2001 19:23:09 +1000, Mark Pritchard wrote:
> > > >PostgreSQL is written completely in C. The development community
> > > >has shown that it is
> > [snip]
> > > >The administration task can be separated in 2 different tasks:
> > [snip]
> >
> > Isn't this essentially the split between postmaster/workers and a client?
> > i.e. I don't know how much value is added by introducing another
> > communication protocol when JDBC would work fine. From my understanding of
> > the users API you can handle pretty much everything other than pg_dump. Eg
> > CREATE USER, CREATE DATABASE etc can all be issued from a client using
> > standard PostgreSQL SQL.
> >
> > I'd have to cast my vote on the Java frontend.
> >
> > Cheers,
> >
> > Mark Pritchard
> >
> 
> 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.

Actually we could start it by offering the standard SQL92 wiews for
system 
tables and PG-standard PL/PGSQLfunctions for things that can't currently
be 
done in SQL standard way, like removing primary key or dropping a
column.

Having _one_ _documented_ way for even the things that psql's \d
commands can 
show would make writing other system tools much easier.

And yes, I think a separate deamon approach will be needed for many
things 
anyway (like changing pg_hba.conf or firewall rules, showing system
logs, ...).

seems that something using some standard protocol (I would favour
XML-RPC (for 
simplicity) over https (for security)) to expose actions would be a good 
candidate for the daemon thingie.

--------------
Hannu

Thu, 21 Jun 2001 19:48:32 +0200
Hannu Krosing <hannu@tm.ee>
Re: Universal admin frontend