Return-Path: Message-ID: From: Claudio Takahasi To: bluez-devel@lists.sourceforge.net Subject: Re: [Bluez-devel] bluetoothd D-Bus interface proposals(draft 00.05) In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_730_30828703.1125350006533" References: <8c9e090508220504100c127e@mail.gmail.com> <5256d0b050822053737c9cd8f@mail.gmail.com> <9307f5f2050822072659387e3b@mail.gmail.com> <1124721252.23599.53.camel@pegasus> <1124733046.23599.81.camel@pegasus> Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net Reply-To: bluez-devel@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ development List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 29 Aug 2005 18:13:26 -0300 ------=_Part_730_30828703.1125350006533 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi folks, Sorry annoy you again, but would like received more suggestions and close= =20 this discussion. Marcel, I remember you comment something about improve the sdpd, could you= =20 be more clear? The core implementation (bluetoothd) and some hci functions are ready. I am= =20 just waiting finish the specification. http://www.cin.ufpe.br/~ckt/bluez Regards, Claudio. On 8/22/05, Claudio Takahasi wrote: >=20 > Hi folks, >=20 > The discussion focus moved to address multiple adapters. In the next > BlueZ D-Bus specification I will handle only the default > adapter(BDADDR_ANY). >=20 > There are other points that I want feebacks. > * Unify rfcomm and dun D-Bus interfaces/path? > * Provide IP parameter setup. Is it necessary provide D-Bus services > to configurate IP address, netmask, ...? > * Provide services for automatic bridge creation(PAN context). Is really= =20 > useful? > * Where provide pair/authentication? Pair services does not belongs to > a nice object path. Maybe should be "org.bluez.bluetoothd.security" > * How SDP should work? How should be the interaction between SDP and > the profiles in order to save memory, avoid code dupplication and use > cache? > * Multi level signals. For connection, disconnections and signal level > would make sense to have both low level signals(eg: hci vs. pan). Is > it really necessary? > * Remove "Sig", "Req" from the method name. The type field in the > header can be used to identify the message type(method call, method > return, message error or signal), but in my opinion we must keep to > make messages more clear. >=20 > The latest specification (draft 00.05) can be found at: > http://www.cin.ufpe.br/~ckt/bluez >=20 > Regards, > Claudio. >=20 > On 8/22/05, Marcel Holtmann wrote: > > Hi Claudio, > > > > > After this long discussion I think control multiple apdaters > > > will not be easy. If we register multiple paths will not be easy > > > map device register/unregister to D-Bus paths. When the user > > > remove the default dongle the D-Bus path should be unregistered and > > > the default adapter should be changed. > > > > never was and never will be ;) > > > > > Considering that bluez daemons are using the BDADDR_ANY. The D-Bus > > > services should use the same approach. I agree that the default > > > adapter must go through the kernel. > > > > > > Is there a way/interface to change the default adapter in the kernel? > > > > No. It has a simple route heuristic and normally uses the first adapter > > that is marked as up and is not a raw device. Unless the destination is > > not itself. > > > > This means that the default adapter depends on the destination which is > > not easy to configure. > > > > Regards > > > > Marcel > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20 > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &= =20 > QA > > Security * Process Improvement & Measurement *=20 > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Bluez-devel mailing list > > Bluez-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bluez-devel > > > ------=_Part_730_30828703.1125350006533 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi folks,

Sorry annoy you again, but would like received more suggestions and close t= his discussion.

Marcel, I remember you comment something about improve the sdpd, could you = be more clear?

The core implementation (bluetoothd) and some hci functions are ready. I am= just waiting finish the specification.

http://www.cin.ufpe.br/~ckt/b= luez

Regards,
Claudio.



On 8/22/05, Claudio Takahasi <ck= takahasi@gmail.com> wrote:
Hi folks,

The discussion focus moved to address multiple adapters. I= n the next
BlueZ D-Bus specification I will handle only the default
a= dapter(BDADDR_ANY).

There are other points that I want feebacks.
* Unify rfcomm and dun D-Bus interfaces/path?
* Provide IP parameter= setup. Is it necessary provide D-Bus services
to configurate IP address= , netmask, ...?
* Provide services for automatic bridge creation(PAN con= text). Is really useful?
* Where provide pair/authentication? Pair services does not belongs to<= br>a nice object path. Maybe should be "org.bluez.bluetoothd.security&= quot;
* How SDP should work? How should be the interaction between SDP a= nd
the profiles in order to save memory, avoid code dupplication and usecache?
* Multi level signals. For connection, disconnections and signa= l level
would make sense to have both low level signals(eg: hci vs. pan)= . Is
it really necessary?
* Remove "Sig", "Req" from = the method name. The type field in the
header can be used to identify th= e message type(method call, method
return, message error or signal), but= in my opinion we must keep to
make messages more clear.

The latest specification (draft 00.05)= can be found at:
http://w= ww.cin.ufpe.br/~ckt/bluez

Regards,
Claudio.

On 8/22/05= , Marcel Holtmann < marcel@holtmann.org> wrote:> Hi Claudio,
>
> > After this long discussion I think = control multiple apdaters
> > will not be easy. If we register mul= tiple paths will not be easy
> > map device register/unregister to D-Bus paths. When the user<= br>> > remove the default dongle the D-Bus path should be unregistere= d and
> > the default adapter should be changed.
>
> n= ever was and never will be ;)
>
> > Considering that bluez daemons are using the BDADDR_A= NY. The D-Bus
> > services should use the same approach. I agree t= hat the default
> > adapter must go through the kernel.
> &g= t;
> > Is there a way/interface to change the default adapter in the= kernel?
>
> No. It has a simple route heuristic and normally u= ses the first adapter
> that is marked as up and is not a raw device.= Unless the destination is
> not itself.
>
> This means that the default adapter de= pends on the destination which is
> not easy to configure.
>> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net= email is Sponsored by the Better Software Conference & EXPO
> Se= ptember 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Team= s * Testing & QA
> Security * Process Improvement & Measureme= nt * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-deve= l mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

------=_Part_730_30828703.1125350006533-- ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel