public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
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

  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