On Mon, 13 Jan 2003 02:55:10 +0200 (IST)
Tzafrir Cohen <[EMAIL PROTECTED]> wrote:
> The programs provided the API that was originally needed: |lpr
Evgeny does have a point in that some applications need a lot more control
than just submitting a job (e.g: display a list of printers, listing the
characteristics of specific printer [paper type, etc.], locating the closest
priner [LOC comes to mind...]) non of this type of config is easily accessible
from the conventional print spoolers.
> Also: xml still doesn't allow me to easily:
>
> *font: fixed
In this example it does. The correct way to implement this in XML is via
an XPath/XQuery expression [which should be against the available fonts].
I completely agree though that syntactically the XML et-al are far
worse than the elegant XResources syntax.
> This is because XML assumes a tree structure, and this wildcar below
> applies toall leaves wirt the name "font". So you see: a tree schema
> doesn't always work...
Agreed (although the previous example didn't demonstrated it).
> And I still don't l;ike the current gconf: it requires an extra daemon
Worse! IIRC it's an extra daemon *per user*
Also, replying to Evgeny:
Having a standard and powerfull config mechanism is a GoodThing(tm)
However, some "config" files in Unix/Linux are actually code
(e.g: shell scripts, .emacs) which obviousely are more general
than any config scheme you may come with.
If the proposed config mechanism is very general, it would
bloat simple applications and their authors (justfully) won't
use it.
I do accept your observation, that in *many cases* there was no
good reason to invent yet another poorly engineered config
mechanism. I would suggest though, that a more realistic goal
should be to *minimize* the number of different config types.
For example:
- A linear key=value pairs (e.g: INI files)
- Hierarchic config (e.g: static XML)
- Dynamic config (e.g: Registry/gconf)
- Inherited config (e.g: environment variables)
- .... where do I fit Xresources?
- ... others
So we may try to converge to some "best-of-breed" API in each
category. Some categories may even need alternative selection
due do special constraints:
- On small footprint systems you trade flexibility for
footprint.
- Some maintenance modes (e.g: single user) may force you
to manual config, so you cannot depend on running config
deamons (gconf, *SQL, etc.)
So you may want both "full-blown" API and a "minimal-API" for
the same category (similar to glibc and dietlibc).
----------------------------------------------------------------
Oron Peled Voice/Fax: +972-4-8228492
[EMAIL PROTECTED] http://www.actcom.co.il/~oron
Code Red, Blue or Green there all a symptom of a far more pervasive
and insidious virus, it costs around $200.
-anonymous
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
