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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox