From: Marcel Holtmann <marcel@holtmann.org>
To: Eugene Crosser <crosser@average.org>
Cc: "Fred Schättgen" <bluez-devel@schaettgen.de>,
"BlueZ Mailing List" <bluez-devel@lists.sourceforge.net>,
"GNOME Bluetooth Mailing List" <gnome-bluetooth@usefulinc.com>
Subject: Re: [gnome-bluetooth] Re: [Bluez-devel] What stuff in gnome-bluetooth does, and ideas for its future
Date: Fri, 30 Jan 2004 20:06:21 +0100 [thread overview]
Message-ID: <1075489580.26729.208.camel@pegasus> (raw)
In-Reply-To: <1075488593.21795.37.camel@ariel.sovam.com>
Hi Eugene,
> > the best place for Unix sockets is /tmp
>
> Or /var/<something>, and not only sockets, but other variable data as
> well. /etc may be on a read-only filesystem. Imagine a bluetooth
> gadget based on Linux burnt in ROM.
No. The /tmp directory will be cleared on every boot and the Unix socket
must not survive reboots. We can use /var/bluetooth for our databases.
> (I continue to think that binary helper is a viable option for the low
> level interface. It is very scalable: "lean" implementation for very
> simple environments may be cut down to just a few lines of shell
> script. "Rich" implementation may use whatever database, and/or relay
> requests to other programs over D-BUS, or CORBA, or anything...)
Calling an extra program for every transaction "costs" too much and it
raises too many security issues. If you talk about the PIN helper I
think we would have in future per BD_ADDR stored PIN's, D-BUS and
calling a helper script.
Regards
Marcel
_______________________________________________
gnome-bluetooth mailing list
gnome-bluetooth@usefulinc.com
http://lists.usefulinc.com/mailman/listinfo/gnome-bluetooth
next prev parent reply other threads:[~2004-01-30 19:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1064593223.12843.127.camel@saag>
[not found] ` <1067882864.15593.326.camel@dhcp-116.surrey.redhat.com>
[not found] ` <1067906859.15607.48.camel@saag>
2004-01-28 23:04 ` [gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future Fredrik Noring
2004-01-29 0:50 ` Fredrik Noring
2004-01-29 11:09 ` Edd Dumbill
2004-01-29 15:22 ` Marcel Holtmann
2004-01-29 15:32 ` Edd Dumbill
2004-01-29 18:14 ` Fredrik Noring
2004-01-30 17:45 ` Fredrik Noring
2004-01-30 18:18 ` Marcel Holtmann
2004-01-30 20:31 ` Fredrik Noring
2004-01-29 11:30 ` [Bluez-devel] " Fred Schättgen
2004-01-29 18:44 ` Fredrik Noring
2004-01-29 20:19 ` [Bluez-devel] " Fred Schättgen
2004-01-30 18:10 ` [gnome-bluetooth] " Fredrik Noring
2004-01-30 18:26 ` Marcel Holtmann
2004-01-30 18:49 ` Eugene Crosser
2004-01-30 19:06 ` Marcel Holtmann [this message]
2004-01-30 20:41 ` Fredrik Noring
2004-01-30 20:35 ` Fredrik Noring
2004-01-30 18:49 ` [Bluez-devel] name cache Fred Schättgen
2004-01-30 20:54 ` 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=1075489580.26729.208.camel@pegasus \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
--cc=bluez-devel@schaettgen.de \
--cc=crosser@average.org \
--cc=gnome-bluetooth@usefulinc.com \
/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.