--- "Anuj Verma (Kevin)" <kevin.verma(a)gmail.com> wrote:
On Fri, 13 Apr 2007 09:42:53 +0200, Matej Cepl wrote:
> Jane Dogalt <jdogalt(a)yahoo.com> writes:
>> I for one really like the idea, with one extra caveat- Make sure
there
>> is also a good batch/commandline (read: scriptable) backend in
addition
>> to one or more GUI backends, and possibly a curses-ish text based
one
>> as well. (but my focus is on being able to easily control any
>> functionality from a bash script).
>
> +1
>
> This is the point which should be stressed a lot -- I mean, still
the
> main customers of RH are on server side and inability to use some
tools
> without installing gnome (ehm, ehm, gnome-power-manager) seriously
> hurts. I know this is fedora list, but still there are some people
who
> use Fedora-based distros on servers, right?
>
> Best,
>
> Matej
+1
Yes, lot of people seems to be using Fedora for servers. I agree the
problem of config tools has to be re-approached. Distinction between
backend and front-ends is desired.
I have my own lame view how this should be approached, I regret if
some
might not agree because I am just a tech guy I hope someone else can
improve on it.
+ s-c-* tools have been done very well over the years
+ the development of s-c-* further should consider a backend and
frontends in:
-> Gnome
-> KDE/Qt
-> NCurses
-> Web?
* More or less we have discussed, but web frontend is what I cite as
more
important. Once we have a backend in place, building a web based
front
end is always quick and easy, that also helps speed up development
and
testing. I believe there are various other advantages of such a
development trend for s-c-*
* I dully notice it might not be appropriate for every s-c-* tool to
have
a web front-end, maybe someone else can help share their vision on
this
point.
* This will also require a daemon to host s-c-* tools on a Fedora
host,
maybe something can be figured out ?
This all might sound like webmin kind of approach but I consider
s-c-*
tools have worked very well and neat than webmin, besides that, fresh
ideas can do better. I had this in mind for a long while and I just
felt
sharing it across on this thread.
Just for the record, my brain wasn't working the day I posted that
original thing, and obviously I switched the meanings of frontend(ui)
and backend(actual system modifier to reflect new config choices).
I do like the idea of standardizing everything, and having a
webmin(ish) GUI _frontend_ to everything, as well as purely scriptable
commandline frontend (and the eye candy native desktop gtk frontend).
It was mentioned that multiple frontends would be problematic due to
them losing sync and supporting more or less features. Obviously if
that were allowed to happen, the whole thing is a bad idea. IMO the
way to keep it a good idea, is to _enforce_ all the front ends exposing
_all_ of the functionality.
I.e.
$ system-config-X --help
would _by definition_(enforced policy) show you how to use all possible
functionality from the commandline (or if its really a ton of stuff,
maybe a 'try --manpage for full usage').
Then, I would expect all other frontends to be required to expose all
of that functionality. Perhaps in a primitive way ala firefox's
about::config. But all there in some form nonetheless. (i.e. the GUIs
could be allowed to go nuts with eye candy UIs, but they must all have
some brute force escape to a simple interface exposing all
functionality, ala about::config).
Anyway, just my 2 cents. Mainly I just wanted to correct my
frontend/backend butchery in the original quote, not that it appears to
have corrupted the rest of the discussion.
-dmc/jdog
____________________________________________________________________________________Looking
for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/