Hi folks,

Sorry annoy you again, but would like received more suggestions and close 
this 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/bluez

Regards,
Claudio.



On 8/22/05, Claudio Takahasi <cktakahasi@gmail.com> wrote:
> 
> Hi folks,
> 
> The discussion focus moved to address multiple adapters. In the next
> BlueZ D-Bus specification I will handle only the default
> adapter(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 context). Is really 
> 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.
> 
> The latest specification (draft 00.05) can be found at:
> http://www.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 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 
> 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
> >
>