Marcel,
Three questions:
Have you given any more thought as to how the RFCOMM channels are managed by
the DBus Service API? The same goes for L2CAP. From what I understand the
current implementation depends on clients to know what is available...
Will there be a lower-level SDP registration framework for the local device?
E.g. to be able to manually register records in binary/XML format without
creating a service agent?
Most importantly, do you have plans for local versions of
array{uint32} GetRemoteServiceHandles(string address, string
match)
and
array{byte} GetRemoteServiceRecord(string address, uint32
handle)
?
-Denis
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > > So hcid will never be responsible for allocating rfcomm channels? I'm
> > > not sure that's a good idea, since everybody will implement it themselves
> > > (and probably get it wrong anyway)
> >
> > hcid can never be responsible for that, because that is the job of the
> > kernel. However I am playing with the idea of an RFCOMM server in form
> > of rfcommd in userspace that will allow simple RFCOMM based application
> > and services.
> >
> > For the more complex ones you have to do it by yourself anyway. And you
> > should make it open source anyway so we can tell you what went wrong ;)
>
> Open sourcing it shouldn't be a problem. Besides, our case is easy, we assume
> we _own_ the device ;)
>
> I'm more thinking of KDE/GNOME useage and meshing with command line daemons.
> I find it annoying that I have to know all the rfcomm channels, what they're
> used by etc, as is the case now. If there was a framework for doing this
> intelligently, I think it would be of great benefit to everyone. The only
> place to put it seems to be hcid at this time.
actually you can ask the kernel to assign you the next free RFCOMM
channel if you really want to. That works perfectly fine and should be
enough for the complex applications.
If anyone mixes D-Bus and non D-Bus way of doing configuration and they
screw up, then I can't help them. We try to take everything possible
into account, but there are limits.
> > > I see two advantages to doing this. The main use case would be to
> > > deprecate some aspects of sdptool and all the hairy code in there that
> > > does the registration. Move all of it to XML/Binary files. The second
> > > would be the completeness of the DBUS API.
> >
> > I am not buying the completeness argument. It is as simple as we don't
> > have a SetAddress method.
> >
> > The hairy code in sdptool is only for development and extending the
> > D-Bus API with development interfaces is not what I actually plan to do.
> > It should stay as clean as possible and every method must actually have
> > a user.
>
> I understand, however such things are very useful to people who can't link to
> GPL'd libraries. I seem to recall that DBus API was supposed to address such
> issues as well. I'm not advocating throwing in everything and the kitchen
> sink, but I feel in this particular case it is useful.
They can write a service-agent.c example a like to register their SDP
record without putting the source code under GPL. Again, it is doable,
but going the closed source path is maybe more complex than the open
source way. I can live with that.
> > > Well I can see several useful things you can do:
> > > - If hcid doesn't manage RFCOMM channels, how will an application know
> > > dynamically what channel is available? Such an operation will never be
> > > atomic (another argument for doing it in hcid), but at least you can do
> > > selection semi-intelligently.
> >
> > You should write a full service for any kind of these use cases.
>
> Are you advocating writing a hcid interface for this? E.g.
>
> org.bluez.RfcommChannelAllocator or ...?
As mentioned above. The operation is atomic, because the kernel controls
it. You either can listen on that channel or not. What I meant was that
you have to write your own service for all kinds of things, but that is
the whole point in separating everything into small pieces.
> > > - I can see a GNOME / KDE app that displays all services running on the
> > > local device, and use the UUIDs to identify exactly what type of service
> > > it is (e.g. for icons) without having to rely on Text descriptions from
> > > the DBus Service API.
> >
> > Then I would extend org.bluez.Service to return exactly that
> > information, but the whole intention of the D-Bus based API is to hide
> > as much Bluetooth specific things for the user interfaces as possible.
>
> Hmm, this is a good idea by the way. Perhaps the Service framework should
> extract the Service UUID and make it available when a record is provided?
> I'll try to look into this.
We will do this internally at some point to better support extended
inquiry, but I still don't see any need for an application to know that
kind of information.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thursday 23 November 2006 15:58, Marcel Holtmann wrote:
> > So hcid will never be responsible for allocating rfcomm channels? I'm
> > not sure that's a good idea, since everybody will implement it themselves
> > (and probably get it wrong anyway)
>
> hcid can never be responsible for that, because that is the job of the
> kernel. However I am playing with the idea of an RFCOMM server in form
> of rfcommd in userspace that will allow simple RFCOMM based application
> and services.
>
> For the more complex ones you have to do it by yourself anyway. And you
> should make it open source anyway so we can tell you what went wrong ;)
Open sourcing it shouldn't be a problem. Besides, our case is easy, we assume
we _own_ the device ;)
I'm more thinking of KDE/GNOME useage and meshing with command line daemons.
I find it annoying that I have to know all the rfcomm channels, what they're
used by etc, as is the case now. If there was a framework for doing this
intelligently, I think it would be of great benefit to everyone. The only
place to put it seems to be hcid at this time.
> > I see two advantages to doing this. The main use case would be to
> > deprecate some aspects of sdptool and all the hairy code in there that
> > does the registration. Move all of it to XML/Binary files. The second
> > would be the completeness of the DBUS API.
>
> I am not buying the completeness argument. It is as simple as we don't
> have a SetAddress method.
>
> The hairy code in sdptool is only for development and extending the
> D-Bus API with development interfaces is not what I actually plan to do.
> It should stay as clean as possible and every method must actually have
> a user.
I understand, however such things are very useful to people who can't link to
GPL'd libraries. I seem to recall that DBus API was supposed to address such
issues as well. I'm not advocating throwing in everything and the kitchen
sink, but I feel in this particular case it is useful.
> > Well I can see several useful things you can do:
> > - If hcid doesn't manage RFCOMM channels, how will an application know
> > dynamically what channel is available? Such an operation will never be
> > atomic (another argument for doing it in hcid), but at least you can do
> > selection semi-intelligently.
>
> You should write a full service for any kind of these use cases.
Are you advocating writing a hcid interface for this? E.g.
org.bluez.RfcommChannelAllocator or ...?
>
> > - I can see a GNOME / KDE app that displays all services running on the
> > local device, and use the UUIDs to identify exactly what type of service
> > it is (e.g. for icons) without having to rely on Text descriptions from
> > the DBus Service API.
>
> Then I would extend org.bluez.Service to return exactly that
> information, but the whole intention of the D-Bus based API is to hide
> as much Bluetooth specific things for the user interfaces as possible.
Hmm, this is a good idea by the way. Perhaps the Service framework should
extract the Service UUID and make it available when a record is provided?
I'll try to look into this.
-Denis
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > > Have you given any more thought as to how the RFCOMM channels are managed
> > > by the DBus Service API? The same goes for L2CAP. From what I
> > > understand the current implementation depends on clients to know what is
> > > available...
> >
> > yes. That is where the "name" parameter in the XML record is for. You
> > can simply override it with your own values. However this must be
> > application or service specific.
>
> So hcid will never be responsible for allocating rfcomm channels? I'm not
> sure that's a good idea, since everybody will implement it themselves (and
> probably get it wrong anyway)
hcid can never be responsible for that, because that is the job of the
kernel. However I am playing with the idea of an RFCOMM server in form
of rfcommd in userspace that will allow simple RFCOMM based application
and services.
For the more complex ones you have to do it by yourself anyway. And you
should make it open source anyway so we can tell you what went wrong ;)
> > > Will there be a lower-level SDP registration framework for the local
> > > device? E.g. to be able to manually register records in binary/XML format
> > > without creating a service agent?
> >
> > It is there at the moment by using the Bluetooth library. However I have
> > no idea if it will stay there. I don't see any real use case except for
> > debugging and with your enhancement to service-agent.c even that case is
> > not really existent anymore.
>
> I see two advantages to doing this. The main use case would be to deprecate
> some aspects of sdptool and all the hairy code in there that does the
> registration. Move all of it to XML/Binary files. The second would be the
> completeness of the DBUS API.
I am not buying the completeness argument. It is as simple as we don't
have a SetAddress method.
The hairy code in sdptool is only for development and extending the
D-Bus API with development interfaces is not what I actually plan to do.
It should stay as clean as possible and every method must actually have
a user.
> > > Most importantly, do you have plans for local versions of
> > > array{uint32} GetRemoteServiceHandles(string address,
> > > string match)
> > >
> > > and
> > >
> > > array{byte} GetRemoteServiceRecord(string address, uint32
> > > handle)
> > >
> > > ?
> >
> > I thought about that multiple times. Every time I convinced myself to
> > implement it, I failed to find the use case for it.
>
> Well I can see several useful things you can do:
> - If hcid doesn't manage RFCOMM channels, how will an application know
> dynamically what channel is available? Such an operation will never be
> atomic (another argument for doing it in hcid), but at least you can do
> selection semi-intelligently.
You should write a full service for any kind of these use cases.
> - I can see a GNOME / KDE app that displays all services running on the local
> device, and use the UUIDs to identify exactly what type of service it is
> (e.g. for icons) without having to rely on Text descriptions from the DBus
> Service API.
Then I would extend org.bluez.Service to return exactly that
information, but the whole intention of the D-Bus based API is to hide
as much Bluetooth specific things for the user interfaces as possible.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thursday 23 November 2006 15:35, Marcel Holtmann wrote:
> Hi Denis,
>
> > Have you given any more thought as to how the RFCOMM channels are managed
> > by the DBus Service API? The same goes for L2CAP. From what I
> > understand the current implementation depends on clients to know what is
> > available...
>
> yes. That is where the "name" parameter in the XML record is for. You
> can simply override it with your own values. However this must be
> application or service specific.
So hcid will never be responsible for allocating rfcomm channels? I'm not
sure that's a good idea, since everybody will implement it themselves (and
probably get it wrong anyway)
>
> > Will there be a lower-level SDP registration framework for the local
> > device? E.g. to be able to manually register records in binary/XML format
> > without creating a service agent?
>
> It is there at the moment by using the Bluetooth library. However I have
> no idea if it will stay there. I don't see any real use case except for
> debugging and with your enhancement to service-agent.c even that case is
> not really existent anymore.
I see two advantages to doing this. The main use case would be to deprecate
some aspects of sdptool and all the hairy code in there that does the
registration. Move all of it to XML/Binary files. The second would be the
completeness of the DBUS API.
>
> > Most importantly, do you have plans for local versions of
> > array{uint32} GetRemoteServiceHandles(string address,
> > string match)
> >
> > and
> >
> > array{byte} GetRemoteServiceRecord(string address, uint32
> > handle)
> >
> > ?
>
> I thought about that multiple times. Every time I convinced myself to
> implement it, I failed to find the use case for it.
Well I can see several useful things you can do:
- If hcid doesn't manage RFCOMM channels, how will an application know
dynamically what channel is available? Such an operation will never be
atomic (another argument for doing it in hcid), but at least you can do
selection semi-intelligently.
- I can see a GNOME / KDE app that displays all services running on the local
device, and use the UUIDs to identify exactly what type of service it is
(e.g. for icons) without having to rely on Text descriptions from the DBus
Service API.
Regards,
-Denis
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> Have you given any more thought as to how the RFCOMM channels are managed by
> the DBus Service API? The same goes for L2CAP. From what I understand the
> current implementation depends on clients to know what is available...
yes. That is where the "name" parameter in the XML record is for. You
can simply override it with your own values. However this must be
application or service specific.
> Will there be a lower-level SDP registration framework for the local device?
> E.g. to be able to manually register records in binary/XML format without
> creating a service agent?
It is there at the moment by using the Bluetooth library. However I have
no idea if it will stay there. I don't see any real use case except for
debugging and with your enhancement to service-agent.c even that case is
not really existent anymore.
> Most importantly, do you have plans for local versions of
> array{uint32} GetRemoteServiceHandles(string address, string
> match)
>
> and
>
> array{byte} GetRemoteServiceRecord(string address, uint32
> handle)
>
> ?
I thought about that multiple times. Every time I convinced myself to
implement it, I failed to find the use case for it.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel