--- "Anuj Verma (Kevin)" <kevin.verma@xxxxxxxxx> wrote:
> On Fri, 13 Apr 2007 09:42:53 +0200, Matej Cepl wrote:
>
> > Jane Dogalt <jdogalt@xxxxxxxxx> 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/
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
