All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.