From: Marcel Holtmann <marcel@holtmann.org>
To: Fredrik Noring <noring@nocrew.org>
Cc: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] D-Bus interfaces
Date: Mon, 09 Feb 2004 17:30:42 +0100 [thread overview]
Message-ID: <1076344242.6869.231.camel@pegasus> (raw)
In-Reply-To: <1076342741.5263.134.camel@kalkyl.roxen.com>
Hi Fredrik,
> > ask yourself what's the indentation of hcid.conf and how should a
> > computer program know about it. Of course this is possible to handle,
> > but it is always a mess.
>
> hcid can have some standard indentation style but it can also support
> the "--marcel-style" flag for your personal formating preferences. ;)
you don't got my point here. If a system administrator modifies some
settings in complex files like hcid.conf, everyone uses its own
identation and style to make it best readable for themself. And nobody
likes if a program changes a value and introduces some odd styles.
Config files like hcid.conf are build this way, because they can contain
complex configuration. Only the administrator should edit such files.
> > No. If we use a uniform storage, there is no need for a D-Bus interface,
> > because the application can modify the storage directly.
>
> "Plain text files" and "DBus interface" do not exclude each other. It
> would be great to have them both, because they serve different pruposes:
No they don't, but with an D-Bus interface we don't need to have
knowledge about these files, because this is the job of the program that
provides us with this D-Bus interface.
> Plain text files are great for admins, debugging, diagnostics etc.
>
> DBus is great for system tools, Gnome, KDE etc. Besides, the DBus
> interfaces provide a lot more services than just maintaining files.
I was never talking about D-Bus for file maintaining. I talked about a
general interface for different tasks. If it comes to link keys or name
caches, of couse these must be stored somewhere. But you can also store
them on a SQL database in another country. Who cares? That is beyond the
interface and its the job of the program that provides this interface.
> > One of the main ideas is to abstract from the storage of the information.
>
> Agreed. But storage abstraction does not implicate storage obfuscation,
> does it? :)
As already said, I have no problem with plain text files. But hcid.conf
is a configuration file and should only read once at startup. All other
modification have to stored in a configuration storage. If we have stuff
that overlaps, we must find a solution for it.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2004-02-09 16:30 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-08 18:35 [Bluez-devel] D-Bus support Marcel Holtmann
2004-02-08 18:51 ` Fredrik Noring
2004-02-08 19:09 ` Marcel Holtmann
2004-02-08 21:07 ` Fredrik Noring
2004-02-08 22:04 ` Marcel Holtmann
2004-02-08 22:33 ` Fredrik Noring
2004-02-08 21:28 ` [Bluez-devel] D-Bus interfaces Fredrik Noring
2004-02-08 21:54 ` Marcel Holtmann
2004-02-08 22:15 ` Fredrik Noring
2004-02-08 22:31 ` Marcel Holtmann
2004-02-08 22:50 ` Fredrik Noring
2004-02-08 23:19 ` Marcel Holtmann
2004-02-08 23:51 ` Fredrik Noring
2004-02-09 0:38 ` Marcel Holtmann
2004-02-09 7:22 ` Fredrik Noring
2004-02-09 10:06 ` Marcel Holtmann
2004-02-09 10:22 ` Fredrik Noring
2004-02-09 10:38 ` Marcel Holtmann
2004-02-09 10:46 ` Fredrik Noring
2004-02-09 11:03 ` Marcel Holtmann
2004-02-09 11:53 ` Fredrik Noring
2004-02-09 13:01 ` Marcel Holtmann
2004-02-09 13:23 ` Fredrik Noring
2004-02-09 15:46 ` Marcel Holtmann
2004-02-09 16:05 ` Fredrik Noring
2004-02-09 16:30 ` Marcel Holtmann [this message]
2004-02-09 17:04 ` Fredrik Noring
2004-02-11 10:03 ` Fredrik Noring
2004-02-11 13:32 ` Marcel Holtmann
2004-02-11 14:05 ` Fredrik Noring
2004-02-11 16:45 ` Marcel Holtmann
2004-02-11 22:00 ` Fredrik Noring
2004-02-11 22:29 ` Marcel Holtmann
2004-02-11 22:33 ` Fredrik Noring
2004-02-11 12:32 ` Fredrik Noring
2004-02-11 13:28 ` Marcel Holtmann
2004-02-11 14:35 ` Fredrik Noring
2004-02-11 17:05 ` Marcel Holtmann
2004-02-11 22:25 ` Fredrik Noring
2004-02-11 22:42 ` Marcel Holtmann
2004-02-11 22:57 ` Fredrik Noring
2004-02-11 23:14 ` Marcel Holtmann
2004-02-11 23:29 ` Fredrik Noring
2004-02-11 23:36 ` Marcel Holtmann
2004-02-11 23:41 ` Fredrik Noring
2004-02-11 23:46 ` Marcel Holtmann
2004-02-08 23:15 ` Fred Schättgen
2004-02-16 14:46 ` Phil Blundell
2004-02-16 15:36 ` Marcel Holtmann
2004-02-16 15:41 ` Phil Blundell
2004-02-17 22:59 ` Marcel Holtmann
2004-02-17 23:38 ` Philip Blundell
2004-02-17 23:44 ` Marcel Holtmann
2004-02-17 23:49 ` Philip Blundell
2004-02-17 23:57 ` Marcel Holtmann
2004-02-18 0:08 ` Philip Blundell
2004-02-18 0:17 ` Marcel Holtmann
2004-02-18 0:29 ` Philip Blundell
2004-02-19 15:55 ` Fredrik Noring
2004-02-19 16:01 ` Fredrik Noring
2004-02-19 15:52 ` Fredrik Noring
2004-02-19 16:48 ` Phil Blundell
2004-02-20 4:04 ` Fredrik Noring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1076344242.6869.231.camel@pegasus \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
--cc=noring@nocrew.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox