From owner-freebsd-bluetooth@FreeBSD.ORG Tue Dec 6 00:58:50 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 308AD16A41F for ; Tue, 6 Dec 2005 00:58:50 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94E4C43D60 for ; Tue, 6 Dec 2005 00:58:49 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id jB60wiJ19796; Mon, 5 Dec 2005 19:58:45 -0500 Message-ID: <4394E242.7030401@savvis.net> Date: Mon, 05 Dec 2005 16:58:42 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Holtmann References: <9307f5f20512030807x6eadc73cq9d9acc9dd5503a5b@mail.gmail.com> <4391E320.2090006@savvis.net> <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> <43936F6B.1090003@savvis.net> <1133819097.4559.15.camel@localhost.localdomain> In-Reply-To: <1133819097.4559.15.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: Automatic bluetooth device initialization X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2005 00:58:50 -0000 Marcel, >> while i appreciate your effort in this area, i'm skeptical that >> d-bus and/or whatever api will solve this problem. i think, instead >> of introducing yet another compatibility layer that sits on top of >> native api, everyone would be much better off if native api was the >> same. what would solve this problem, imo, is the standard >> (something like posix) that would define api etc. > > I don't really like D-Bus, but it will be the way to go for a general > API for the desktop. It has multiple language bindings already and > our goal is to make it totally generic (no BlueZ specific > definitions). perhaps, we are talking about different things here. i do not really understand what multiple language bindings have do with bluetooth device initialization and lower level api. it very much possible that d-bus is very well suited for inter-application communications in kde/gnome/whatever desktop. after all, this is what it is being developed for. what i do not understand is why d-bus is being pushed all the way down and even suggested as replacement for hci? instead of creating numerous d-bus bluetooth applications that know how to work on particular system, why not just create one d-bus bluetooth application that uses common low level bluetooth api? what about not-kde/gnome/whatever applications (i.e. non-d-bus)? are those just out of luck? i admit kde/gnome folks did a lot of work by integrating bluetooth, but their work can not be re-used :( i wish their work would be in a form of re-usable user space modules. i wish they would make it so anybody can just pick this or that module and re-use it. for example, if i want to run obex file server, i do not have to run kde/gnome/d-bus etc. thanks, max