[Bluez-devel] Bluetooth MIME types and URIs

[Bluez-devel] Bluetooth MIME types and URIs

[Marcel Holtmann]

Hi Folks,

I am working on a Gnome VFS method for Bluetooth and we need to find a
common way for using Bluetooth URIs and their related MIME types. At the
moment I am open for any proposals. So please comment on this topic.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Fred Schaettgen]

On Thursday, 7. July 2005 16:42, Marcel Holtmann wrote:
> Hi Folks,
>
> I am working on a Gnome VFS method for Bluetooth and we need to find a
> common way for using Bluetooth URIs and their related MIME types. At the
> moment I am open for any proposals. So please comment on this topic.

What is this VFS module supposed to do? Device discovery, service discovery=
=2E.?
Oh, wait... did you say Gnome? You are using a graphical desktop? Is your t=
ext=20
terminal broken? *g*

In kdebluetooth we have three ioslaves (which I assume is roughly the same =
as=20
a gnome VFS module):
bluetooth:/ simply do an inquiry and list the devices found
sdp://[xx:xx:xx:xx:xx:xx]/ lists the services of a given device
=46or conveniance it=C2=B4s also possible to replace the [<bdaddr>] with th=
e device=20
name (which is looked up in kdebluetooth=C2=B4s persistant name cache).
The [xx:xx...] syntax is inspired by the syntax used for IPv6 addresses in=
=20
URLs (RFC 2732).
The third ioslave is for a the OBEX file transfer profile, so it=C2=B4s not=
 really=20
relevant here.

=46or the mimetypes of the devices listed by the bluetooth ioslave we use=20
different types for each device class. The mimetypes are called=20
=C2=A8bluetooth/computer-device-class=C2=A8 for instance. afaik the subclas=
s should=20
start with x-, and I=C2=B4m also not sure if the class string =C2=A8bluetoo=
th=C2=A8 is ok,=20
but it works and no one complained...
We could have used a single mimetype for all classes and hardcode the icon.=
=20
Since there are no custom actions for special device classes and since the=
=20
device classes all known in advance, it doesn=C2=B4t really matter how it=
=C2=B4s done.
=46or services (listed by the sdp-ioslave) we use mimetypes like=20
=C2=A8bluetooth/handsfree-profile=C2=A8. For each mimetype file we have a c=
orresponding=20
desktop file which maps a list of UIDs to a mimetype, so new profiles can b=
e=20
installed by third party applications (there aren=C2=B4t any so far, but=20
anyway... ;)
By using different mimetypes for each profile, the user can change the=20
association of bluetooth services with applications. Sometimes it=C2=B4s a =
bit=20
nasty if you want to open a handsfree service with a generic terminal=20
program, that depends only on rfcomm for instance. At least in KDE it seems=
=20
to be impossible to assign two mimetypes to an item. The other solution wou=
ld=20
be a hierarchy among the mimetypes (rfcomm<-handsfree for instance).

Another option would be to use a single mimetype (associated with a helper=
=20
application) for all services and do the service<->application association=
=20
without mimetypes.

When the user finally clicks a service listed by the sdp ioslave, an=20
application must be started and it must be provided with everything it need=
s=20
to know to connect to the given service.
Since in kdebluetooth we chose to start applications directly without the=20
helper mentioned above, we can only pass an URL to the application. This UR=
L=20
must contain not only the bluetooth address, but also the rfcomm (or l2cap=
=20
etc.) channel given in the service record.=20
In kdebluetooth this is encoded like that:
sdp://[00:e0:03:32:00:00]/params?name=3Dfred%27s%206230&rfcommchannel=3D1
The name of the device was =C2=A8Fred=C2=B4s 6230=C2=A8 in this example. Th=
is scheme would=20
allow to append other parameters, for instance for l2cap-based services.
It would also be possible to encode the complete sdp record of the service=
=20
into the URL, but we didn=C2=B4t have any need for it.
Since KDE ships with a URL class, it is pretty easy to extract the device=20
address and the rfcommchannel from such an URL. Gnome surely has an=20
equivalent to KDE=C2=B4s KURL, but for plain C/C++ apps the quoting might m=
ake it=20
more difficult than necessary.

There are several things we didn=C2=B4t implement, like..
=2D browse groups
=2D searching for a given UID instead of browsing everything

In kdebluetooth the ioslaves are used only directly by the user. Applicatio=
ns=20
could also us it internally to search for devices/services, but we chose to=
=20
use BlueZ directly - with some C++-wrappers around it of course, so that it=
=20
looks less scary to people not hacking the kernel all day long.

Now this was just a short overview over the approach of kdebluetooth. The=20
design was mostly driven by our own needs and the limited degrees of freedo=
m=20
that the ioslave framework offers. Squeezing bluetooth into an infrastructu=
re=20
that was once created to browse a file systems make some things more=20
complicated than necessary. KDE developers tend to put everything and his=20
mother into an ioslave, because it=C2=B4s so simple to start, integrates so=
 nicely=20
with the desktop and all the UI comes for free. The problems start when you=
=20
realize that this UI isn=C2=B4t really best for your application.
But anyway, it would certainly be good to agree on a common scheme if you=20
introduce equivalents to our ioslaves in gnome.
If you have kdebluetooth installed you can try =C2=A8kioclient -U ls 'bluet=
ooth:/'=C2=A8=20
etc. in case I forgot some details about the URLs we are using.

regards
=46red

=2D-=20
=46red Schaettgen
bluez-devel@schaettgen.de


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Marcel Holtmann]

Hi Fred,

> > I am working on a Gnome VFS method for Bluetooth and we need to find =
a
> > common way for using Bluetooth URIs and their related MIME types. At =
the
> > moment I am open for any proposals. So please comment on this topic.
>=20
> What is this VFS module supposed to do? Device discovery, service disco=
very..?

all these tasks are done inside bluetoothd (needs to be written) and the
VFS module is used for displaying them. The communication will be done
via D-Bus.

An after-talk beer session at the LinuxTag with one of the D-Bus guys
convinced me that there is no other way that makes sense. I have a rough
design on how these things will interact, but only a bare minimum is
implemented at the moment. The kernel needs an extra event mechanism for
all this stuff and I have to write bluetoothd of course. The basic idea
looks like this:

	kernel <-> bluetoothd <-> applications

The Nautilus integration is the next logical step and this means a
Bluetooth Gnome VFS module. In general I wanna integrate Bluetooth into
the desktop without writing any new applications. My idea is to make it
mostly invisible for the user that they are using Bluetooth.

> Oh, wait... did you say Gnome? You are using a graphical desktop? Is yo=
ur text=20
> terminal broken? *g*

I hope not ;)

> In kdebluetooth we have three ioslaves (which I assume is roughly the s=
ame as=20
> a gnome VFS module):
> bluetooth:/ simply do an inquiry and list the devices found
> sdp://[xx:xx:xx:xx:xx:xx]/ lists the services of a given device
> For conveniance it=B4s also possible to replace the [<bdaddr>] with the=
 device=20
> name (which is looked up in kdebluetooth=B4s persistant name cache).
> The [xx:xx...] syntax is inspired by the syntax used for IPv6 addresses=
 in=20
> URLs (RFC 2732).
> The third ioslave is for a the OBEX file transfer profile, so it=B4s no=
t really=20
> relevant here.

The IO slaves and the Gnome VFS are almost the same.

Another way is to strip the colon from the device address. This method
was used in the ESDP and JSR-82 specifications. I used the latter method
in the URIs for the CUPS backend.

Main question is how we deal with different local devices. We need a
method to specify an optional source. No specification really deals with
multiple Bluetooth devices attached to the same host.

> For the mimetypes of the devices listed by the bluetooth ioslave we use=
=20
> different types for each device class. The mimetypes are called=20
> =A8bluetooth/computer-device-class=A8 for instance. afaik the subclass =
should=20
> start with x-, and I=B4m also not sure if the class string =A8bluetooth=
=A8 is ok,=20
> but it works and no one complained...
> We could have used a single mimetype for all classes and hardcode the i=
con.=20
> Since there are no custom actions for special device classes and since =
the=20
> device classes all known in advance, it doesn=B4t really matter how it=B4=
s done.
> For services (listed by the sdp-ioslave) we use mimetypes like=20
> =A8bluetooth/handsfree-profile=A8. For each mimetype file we have a cor=
responding=20
> desktop file which maps a list of UIDs to a mimetype, so new profiles c=
an be=20
> installed by third party applications (there aren=B4t any so far, but=20
> anyway... ;)
> By using different mimetypes for each profile, the user can change the=20
> association of bluetooth services with applications. Sometimes it=B4s a=
 bit=20
> nasty if you want to open a handsfree service with a generic terminal=20
> program, that depends only on rfcomm for instance. At least in KDE it s=
eems=20
> to be impossible to assign two mimetypes to an item. The other solution=
 would=20
> be a hierarchy among the mimetypes (rfcomm<-handsfree for instance).
>=20
> Another option would be to use a single mimetype (associated with a hel=
per=20
> application) for all services and do the service<->application associat=
ion=20
> without mimetypes.

I think we need at least two different MIME types. One for devices and
one for the service records. Having different types for every UUID is
also a good idea. Thoughts?

Actually I have no ideas for their string representation. Does anybody
know a reference for this?

> When the user finally clicks a service listed by the sdp ioslave, an=20
> application must be started and it must be provided with everything it =
needs=20
> to know to connect to the given service.
> Since in kdebluetooth we chose to start applications directly without t=
he=20
> helper mentioned above, we can only pass an URL to the application. Thi=
s URL=20
> must contain not only the bluetooth address, but also the rfcomm (or l2=
cap=20
> etc.) channel given in the service record.=20
> In kdebluetooth this is encoded like that:
> sdp://[00:e0:03:32:00:00]/params?name=3Dfred%27s%206230&rfcommchannel=3D=
1
> The name of the device was =A8Fred=B4s 6230=A8 in this example. This sc=
heme would=20
> allow to append other parameters, for instance for l2cap-based services.
> It would also be possible to encode the complete sdp record of the serv=
ice=20
> into the URL, but we didn=B4t have any need for it.
> Since KDE ships with a URL class, it is pretty easy to extract the devi=
ce=20
> address and the rfcommchannel from such an URL. Gnome surely has an=20
> equivalent to KDE=B4s KURL, but for plain C/C++ apps the quoting might =
make it=20
> more difficult than necessary.

For these kind of things it would be great to go along with the JSR-82
specification and their ideas of a Bluetooth URI. However I am not 100%
sure about that at the moment, because some of the JSR-82 stuff is crap.

> There are several things we didn=B4t implement, like..
> - browse groups
> - searching for a given UID instead of browsing everything

I don't think that these stuff is needed for the graphical interfaces of
Bluetooth. If people want that, then they should use the command line.

> In kdebluetooth the ioslaves are used only directly by the user. Applic=
ations=20
> could also us it internally to search for devices/services, but we chos=
e to=20
> use BlueZ directly - with some C++-wrappers around it of course, so tha=
t it=20
> looks less scary to people not hacking the kernel all day long.

My current idea is to present that via D-Bus and then use whenever
possible Python as programming language. Not that I am a really good
Python programmer, but it seems reasonable to me.

> Now this was just a short overview over the approach of kdebluetooth. T=
he=20
> design was mostly driven by our own needs and the limited degrees of fr=
eedom=20
> that the ioslave framework offers. Squeezing bluetooth into an infrastr=
ucture=20
> that was once created to browse a file systems make some things more=20
> complicated than necessary. KDE developers tend to put everything and h=
is=20
> mother into an ioslave, because it=B4s so simple to start, integrates s=
o nicely=20
> with the desktop and all the UI comes for free. The problems start when=
 you=20
> realize that this UI isn=B4t really best for your application.
> But anyway, it would certainly be good to agree on a common scheme if y=
ou=20
> introduce equivalents to our ioslaves in gnome.
> If you have kdebluetooth installed you can try =A8kioclient -U ls 'blue=
tooth:/'=A8=20
> etc. in case I forgot some details about the URLs we are using.

Last time I played with the KDE-Bluetooth thing it was working great and
the version included in SuSE 9.3 is really usable. However we need some
kind of standard between Gnome and KDE (and every other desktop). At the
moment my mind is totally open for anything. The more feedback the
better.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Fred Schaettgen]

On Thursday, 7. July 2005 20:13, Marcel Holtmann wrote:
=2E..
> > What is this VFS module supposed to do? Device discovery, service
> > discovery..?
>
> all these tasks are done inside bluetoothd (needs to be written) and the
> VFS module is used for displaying them. The communication will be done
> via D-Bus.
>
> An after-talk beer session at the LinuxTag with one of the D-Bus guys
> convinced me that there is no other way that makes sense.

Indeed. That=B4s also more or less what we are doing. Well, the ioslaves do=
 the=20
inquiry and sdp requests on their own, but the name cache is accessed via=20
DCOP. I wouldn=B4t mind if BlueZ could do part of the work. Qt support for =
dbus=20
wasn=B4t all that good last time I checked, but this will certainly change =
if=20
KDE4 starts using dbus more than just removable media.

> I have a rough=20
> design on how these things will interact, but only a bare minimum is
> implemented at the moment. The kernel needs an extra event mechanism for
> all this stuff and I have to write bluetoothd of course. The basic idea
> looks like this:

What is that extra event mechanism good for? Can=B4t you monitor everything=
 that=20
is needed without new extensions?
Oh, btw. is there a way to get the number of transfered packets/bytes? =20

=2E..
> > The [xx:xx...] syntax is inspired by the syntax used for IPv6 addresses
> > in URLs (RFC 2732).
=2E..
> Another way is to strip the colon from the device address. This method
> was used in the ESDP and JSR-82 specifications. I used the latter method
> in the URIs for the CUPS backend.

Ok, someone flip a coin please ;)

> Main question is how we deal with different local devices. We need a
> method to specify an optional source. No specification really deals with
> multiple Bluetooth devices attached to the same host.

We could simply append the device number to the device address and default =
to=20
the first usable device if that suffix is missing. Like [xx:xx:xx:xx:xx:xx.=
2]=20
for instance. =20
But remember that you are targeting desktop users now. We support several=20
devices only by setting a special environment variable/command line paramet=
er=20
and before that we=B4ve had about one complaint in total regarding missing=
=20
support for multiple adapters. A workaround for special needs is obviously=
=20
enough, no need to complicate the UI for the vast majority with just a sing=
le=20
adapter.

=2E..
[mimetypes used by kde=B4s ioslaves]
=2E..
> I think we need at least two different MIME types. One for devices and
> one for the service records. Having different types for every UUID is
> also a good idea. Thoughts?

Sure, when I said =A8one mimetype=A8 I was talking just about the sdp iosla=
ve=20
which does the services. Do you want to use one VFS module for everything? =
We=20
used to have one kioslave for both device discovery and service listing, bu=
t=20
it=B4s cleaner if it=B4s separated in my eyes.
If you have one mimetype per UUID, then which one do you pick for the file=
=20
item? Or can you assign several mimetypes to one item with gnome=B4s VFS?
That=B4s one of the points where doing bluetooth with kioslaves looked like=
 a=20
not so good idea.

> Actually I have no ideas for their string representation. Does anybody
> know a reference for this?

String representation of what? Mime types? This might help in that case:
http://www.iana.org/assignments/media-types/
I never bothered reading it though.

=2E..
> For these kind of things it would be great to go along with the JSR-82
> specification and their ideas of a Bluetooth URI. However I am not 100%
> sure about that at the moment, because some of the JSR-82 stuff is crap.

If it does all we need - fine. How would a JSR-82 style URL look like to=20
access some service of a device?

> Last time I played with the KDE-Bluetooth thing it was working great and
> the version included in SuSE 9.3 is really usable. However we need some
> kind of standard between Gnome and KDE (and every other desktop). At the
> moment my mind is totally open for anything. The more feedback the
> better.

The metaserver feature of kbluetoothd really shouldn=B4t be KDE-specific in=
 my=20
eyes. It=B4s extremly helpful to implement new services, which can then be=
=20
controlled in a consistent and secure fashion. It proved to work very well=
=20
for us in all the time, but having it implemented in BlueZ (with KDE and=20
Gnome providing just a GUI for it) it might even used by third parties. It=
=B4s=20
hard to sell if it=B4s tied to KDE.

Another service that might be worth sharing is the device discovery. This i=
s a=20
service offered by kbluetoothd which searches for nearby devices regularly =
=20
and starts scripts when devices come and go. It totally sucks UI-wise, but =
it=20
is good for many interesting applications. And if you have more than one=20
application where each one polls for new devices, then it makes a lot of=20
sense to have just a central service doing that on behalf of them.
The biggest problem is how to deal with devices that are not discoverable. =
In=20
kbluetoothd the user (or applications via DCOP) can configure a list of=20
devices that are paged to find out if they are around. But those connection=
=20
attempts don=B4t do any good when you try to use the adapter for something =
else=20
meanwhile.

Will the bluetoothd run in the user session or as root? Maybe it should be=
=20
able to do both, just like the dbus daemon itself. If bluetoothd contains a=
=20
metaserver eventually it should be possible to have it launch applications=
=20
with a GUI, like kbluetoothd is doing now. But we can=B4t start system serv=
ices=20
on demand, even though this can be desirable too.=20

=46red


=2D-=20
=46red Schaettgen
bluez-devel@schaettgen.de


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Marcel Holtmann]

Hi Fred,

> > An after-talk beer session at the LinuxTag with one of the D-Bus guys
> > convinced me that there is no other way that makes sense.
>=20
> Indeed. That=B4s also more or less what we are doing. Well, the ioslave=
s do the=20
> inquiry and sdp requests on their own, but the name cache is accessed v=
ia=20
> DCOP. I wouldn=B4t mind if BlueZ could do part of the work. Qt support =
for dbus=20
> wasn=B4t all that good last time I checked, but this will certainly cha=
nge if=20
> KDE4 starts using dbus more than just removable media.

I will move the device and service discovery into bluetoothd and also
the name cache. Actually hcid already maintains a name cache, but at the
moment you can access it only via the filesystem.

> > I have a rough=20
> > design on how these things will interact, but only a bare minimum is
> > implemented at the moment. The kernel needs an extra event mechanism =
for
> > all this stuff and I have to write bluetoothd of course. The basic id=
ea
> > looks like this:
>=20
> What is that extra event mechanism good for? Can=B4t you monitor everyt=
hing that=20
> is needed without new extensions?

But you need to do everything twice. Inside the kernel and then again in
userspace. The kernel needs to keep track of a lot of stuff anyway and
so I don't wanna redo that in userspace.

The best example is the Inquiry Result with RSSI event. Some vendor got
it wrong and so I had to implement a workaround in the kernel, in hcid
and in hcidump. The hcidump part will never go away, because I need to
keep it separate to be able to detect errors, but the kernel and hcid
(bluetoothd in the future) shouldn't need to do that twice.

> Oh, btw. is there a way to get the number of transfered packets/bytes? =
=20

The "struct hci_dev_info" contain them. Check hciconfig for an example.

> > > The [xx:xx...] syntax is inspired by the syntax used for IPv6 addre=
sses
> > > in URLs (RFC 2732).
> ...
> > Another way is to strip the colon from the device address. This metho=
d
> > was used in the ESDP and JSR-82 specifications. I used the latter met=
hod
> > in the URIs for the CUPS backend.
>=20
> Ok, someone flip a coin please ;)

I checked the RFC 2732 and I think both are fine. Maybe it is a good
idea to also support both.

> > Main question is how we deal with different local devices. We need a
> > method to specify an optional source. No specification really deals w=
ith
> > multiple Bluetooth devices attached to the same host.
>=20
> We could simply append the device number to the device address and defa=
ult to=20
> the first usable device if that suffix is missing. Like [xx:xx:xx:xx:xx=
:xx.2]=20
> for instance. =20

I don't like it. My thoughts were something like:

	hci0@aabbccddeeff or 112233445566@aabbccddeeff

But actually I must admit I am not really convinced.

> But remember that you are targeting desktop users now. We support sever=
al=20
> devices only by setting a special environment variable/command line par=
ameter=20
> and before that we=B4ve had about one complaint in total regarding miss=
ing=20
> support for multiple adapters. A workaround for special needs is obviou=
sly=20
> enough, no need to complicate the UI for the vast majority with just a =
single=20
> adapter.

This is no argument for me. We always will have the special case where
only one adapter exists and BDADDR_ANY is enough, but this is Linux and
we do it the right way and support everything possible. You need to redo
your thinking. Multiple adapters is the normal case and only one adapter
is a special case.

And if I start using graphical toys for Bluetooth then they must support
it, because for me the normal case is three attached adapters ;)

> > I think we need at least two different MIME types. One for devices an=
d
> > one for the service records. Having different types for every UUID is
> > also a good idea. Thoughts?
>=20
> Sure, when I said =A8one mimetype=A8 I was talking just about the sdp i=
oslave=20
> which does the services. Do you want to use one VFS module for everythi=
ng? We=20
> used to have one kioslave for both device discovery and service listing=
, but=20
> it=B4s cleaner if it=B4s separated in my eyes.
> If you have one mimetype per UUID, then which one do you pick for the f=
ile=20
> item? Or can you assign several mimetypes to one item with gnome=B4s VF=
S?
> That=B4s one of the points where doing bluetooth with kioslaves looked =
like a=20
> not so good idea.

I don't see the advantage of having two different VFS modules for device
and service discovery. And since both are only presenting stuff that can
be retrieved from bluetoothd they won't be highly complex.

Since Nautilus is supporting "Open with" it might be possible to assign
multiple applications to one MIME type. This also means that we need
different MIME types for each service/profile.

> > Actually I have no ideas for their string representation. Does anybod=
y
> > know a reference for this?
>=20
> String representation of what? Mime types? This might help in that case=
:
> http://www.iana.org/assignments/media-types/
> I never bothered reading it though.

It was a long time ago when I read the RFC 2046. However after looking
through it, I think we must use the application main type with the x-
subtype. What about stuff like this:

	application/x-bt.device
	application/x-bt.service

	application/x-bt.handsfree

On the other hand I remembered that the BIP already needed special MIME
types and it seems they are using x-bt/img-listing and so on for it.

> > For these kind of things it would be great to go along with the JSR-8=
2
> > specification and their ideas of a Bluetooth URI. However I am not 10=
0%
> > sure about that at the moment, because some of the JSR-82 stuff is cr=
ap.
>=20
> If it does all we need - fine. How would a JSR-82 style URL look like t=
o=20
> access some service of a device?

They only define btspp:, btl2cap: and btgoep: and it is mostly used for
protocol transports. As I said, some of it is crap.

> > Last time I played with the KDE-Bluetooth thing it was working great =
and
> > the version included in SuSE 9.3 is really usable. However we need so=
me
> > kind of standard between Gnome and KDE (and every other desktop). At =
the
> > moment my mind is totally open for anything. The more feedback the
> > better.
>=20
> The metaserver feature of kbluetoothd really shouldn=B4t be KDE-specifi=
c in my=20
> eyes. It=B4s extremly helpful to implement new services, which can then=
 be=20
> controlled in a consistent and secure fashion. It proved to work very w=
ell=20
> for us in all the time, but having it implemented in BlueZ (with KDE an=
d=20
> Gnome providing just a GUI for it) it might even used by third parties.=
 It=B4s=20
> hard to sell if it=B4s tied to KDE.

Before talking about any metaserver, I need to resolve some other basic
issues like authentication, authorization etc.

> Another service that might be worth sharing is the device discovery. Th=
is is a=20
> service offered by kbluetoothd which searches for nearby devices regula=
rly =20
> and starts scripts when devices come and go. It totally sucks UI-wise, =
but it=20
> is good for many interesting applications. And if you have more than on=
e=20
> application where each one polls for new devices, then it makes a lot o=
f=20
> sense to have just a central service doing that on behalf of them.
> The biggest problem is how to deal with devices that are not discoverab=
le. In=20
> kbluetoothd the user (or applications via DCOP) can configure a list of=
=20
> devices that are paged to find out if they are around. But those connec=
tion=20
> attempts don=B4t do any good when you try to use the adapter for someth=
ing else=20
> meanwhile.

The inquiries in background is something I don't really like about it,
because for some devices this is simply disturbing and if you play music
over A2DP you might kill the audio stream with it. However I wanna move
that all into bluetoothd (including somekind of SDP cache).

> Will the bluetoothd run in the user session or as root? Maybe it should=
 be=20
> able to do both, just like the dbus daemon itself. If bluetoothd contai=
ns a=20
> metaserver eventually it should be possible to have it launch applicati=
ons=20
> with a GUI, like kbluetoothd is doing now. But we can=B4t start system =
services=20
> on demand, even though this can be desirable too.=20

It will be root only, because otherwise it can't listen for kernel
events. We also need one central daemon to deal with all the stuff and
so a session version makes no sense. However there is also no need it,
because it will communicate only over D-Bus and this can be made session
aware. The D-Bus also have somekind of activation mechanism that should
make it possible to start application, but I never looked at that. Right
now there are other things with higher priority.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Claudio Takahasi]

Hi folks,

I am not complete aware of all subjects under discussion, but I would
like comment some points ...

On 7/8/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Fred,
>=20
> > > An after-talk beer session at the LinuxTag with one of the D-Bus guys
> > > convinced me that there is no other way that makes sense.
> >
> > Indeed. That=B4s also more or less what we are doing. Well, the ioslave=
s do the
> > inquiry and sdp requests on their own, but the name cache is accessed v=
ia
> > DCOP. I wouldn=B4t mind if BlueZ could do part of the work. Qt support =
for dbus
> > wasn=B4t all that good last time I checked, but this will certainly cha=
nge if
> > KDE4 starts using dbus more than just removable media.
>=20
> I will move the device and service discovery into bluetoothd and also
> the name cache. Actually hcid already maintains a name cache, but at the
> moment you can access it only via the filesystem.
>=20
> > > I have a rough
> > > design on how these things will interact, but only a bare minimum is
> > > implemented at the moment. The kernel needs an extra event mechanism =
for
> > > all this stuff and I have to write bluetoothd of course. The basic id=
ea
> > > looks like this:
> >
> > What is that extra event mechanism good for? Can=B4t you monitor everyt=
hing that
> > is needed without new extensions?
>=20
> But you need to do everything twice. Inside the kernel and then again in
> userspace. The kernel needs to keep track of a lot of stuff anyway and
> so I don't wanna redo that in userspace.
>=20
> The best example is the Inquiry Result with RSSI event. Some vendor got
> it wrong and so I had to implement a workaround in the kernel, in hcid
> and in hcidump. The hcidump part will never go away, because I need to
> keep it separate to be able to detect errors, but the kernel and hcid
> (bluetoothd in the future) shouldn't need to do that twice.
>=20
> > Oh, btw. is there a way to get the number of transfered packets/bytes?
>=20
> The "struct hci_dev_info" contain them. Check hciconfig for an example.
>=20
> > > > The [xx:xx...] syntax is inspired by the syntax used for IPv6 addre=
sses
> > > > in URLs (RFC 2732).
> > ...
> > > Another way is to strip the colon from the device address. This metho=
d
> > > was used in the ESDP and JSR-82 specifications. I used the latter met=
hod
> > > in the URIs for the CUPS backend.
> >
> > Ok, someone flip a coin please ;)
>=20
> I checked the RFC 2732 and I think both are fine. Maybe it is a good
> idea to also support both.
>=20
> > > Main question is how we deal with different local devices. We need a
> > > method to specify an optional source. No specification really deals w=
ith
> > > multiple Bluetooth devices attached to the same host.
> >
> > We could simply append the device number to the device address and defa=
ult to
> > the first usable device if that suffix is missing. Like [xx:xx:xx:xx:xx=
:xx.2]
> > for instance.
>=20
> I don't like it. My thoughts were something like:
>=20
>         hci0@aabbccddeeff or 112233445566@aabbccddeeff
>=20
> But actually I must admit I am not really convinced.
>=20
> > But remember that you are targeting desktop users now. We support sever=
al
> > devices only by setting a special environment variable/command line par=
ameter
> > and before that we=B4ve had about one complaint in total regarding miss=
ing
> > support for multiple adapters. A workaround for special needs is obviou=
sly
> > enough, no need to complicate the UI for the vast majority with just a =
single
> > adapter.
>=20
> This is no argument for me. We always will have the special case where
> only one adapter exists and BDADDR_ANY is enough, but this is Linux and
> we do it the right way and support everything possible. You need to redo
> your thinking. Multiple adapters is the normal case and only one adapter
> is a special case.
>=20
> And if I start using graphical toys for Bluetooth then they must support
> it, because for me the normal case is three attached adapters ;)
>=20
> > > I think we need at least two different MIME types. One for devices an=
d
> > > one for the service records. Having different types for every UUID is
> > > also a good idea. Thoughts?
> >
> > Sure, when I said =A8one mimetype=A8 I was talking just about the sdp i=
oslave
> > which does the services. Do you want to use one VFS module for everythi=
ng? We
> > used to have one kioslave for both device discovery and service listing=
, but
> > it=B4s cleaner if it=B4s separated in my eyes.
> > If you have one mimetype per UUID, then which one do you pick for the f=
ile
> > item? Or can you assign several mimetypes to one item with gnome=B4s VF=
S?
> > That=B4s one of the points where doing bluetooth with kioslaves looked =
like a
> > not so good idea.
>=20
> I don't see the advantage of having two different VFS modules for device
> and service discovery. And since both are only presenting stuff that can
> be retrieved from bluetoothd they won't be highly complex.
>=20
> Since Nautilus is supporting "Open with" it might be possible to assign
> multiple applications to one MIME type. This also means that we need
> different MIME types for each service/profile.
>=20
> > > Actually I have no ideas for their string representation. Does anybod=
y
> > > know a reference for this?
> >
> > String representation of what? Mime types? This might help in that case=
:
> > http://www.iana.org/assignments/media-types/
> > I never bothered reading it though.
>=20
> It was a long time ago when I read the RFC 2046. However after looking
> through it, I think we must use the application main type with the x-
> subtype. What about stuff like this:
>=20
>         application/x-bt.device
>         application/x-bt.service
>=20
>         application/x-bt.handsfree
>=20
> On the other hand I remembered that the BIP already needed special MIME
> types and it seems they are using x-bt/img-listing and so on for it.
>=20
> > > For these kind of things it would be great to go along with the JSR-8=
2
> > > specification and their ideas of a Bluetooth URI. However I am not 10=
0%
> > > sure about that at the moment, because some of the JSR-82 stuff is cr=
ap.
> >
> > If it does all we need - fine. How would a JSR-82 style URL look like t=
o
> > access some service of a device?
>=20
> They only define btspp:, btl2cap: and btgoep: and it is mostly used for
> protocol transports. As I said, some of it is crap.
>=20
> > > Last time I played with the KDE-Bluetooth thing it was working great =
and
> > > the version included in SuSE 9.3 is really usable. However we need so=
me
> > > kind of standard between Gnome and KDE (and every other desktop). At =
the
> > > moment my mind is totally open for anything. The more feedback the
> > > better.
> >
> > The metaserver feature of kbluetoothd really shouldn=B4t be KDE-specifi=
c in my
> > eyes. It=B4s extremly helpful to implement new services, which can then=
 be
> > controlled in a consistent and secure fashion. It proved to work very w=
ell
> > for us in all the time, but having it implemented in BlueZ (with KDE an=
d
> > Gnome providing just a GUI for it) it might even used by third parties.=
 It=B4s
> > hard to sell if it=B4s tied to KDE.
>=20
> Before talking about any metaserver, I need to resolve some other basic
> issues like authentication, authorization etc.
[Claudio Takahasi]
I am not understaning how the metaserver will work. How the current bluez=
=20
daemons (pand, dund, hidd, rfcomm, ... ) must work with this metaserver.
Could you write more details about the architecture of the metaserver and
how it will interact with the bluez daemons?


>=20
> > Another service that might be worth sharing is the device discovery. Th=
is is a
> > service offered by kbluetoothd which searches for nearby devices regula=
rly
> > and starts scripts when devices come and go. It totally sucks UI-wise, =
but it
> > is good for many interesting applications. And if you have more than on=
e
> > application where each one polls for new devices, then it makes a lot o=
f
> > sense to have just a central service doing that on behalf of them.
> > The biggest problem is how to deal with devices that are not discoverab=
le. In
> > kbluetoothd the user (or applications via DCOP) can configure a list of
> > devices that are paged to find out if they are around. But those connec=
tion
> > attempts don=B4t do any good when you try to use the adapter for someth=
ing else
> > meanwhile.
>=20
> The inquiries in background is something I don't really like about it,
> because for some devices this is simply disturbing and if you play music
> over A2DP you might kill the audio stream with it. However I wanna move
> that all into bluetoothd (including somekind of SDP cache).
>=20
> > Will the bluetoothd run in the user session or as root? Maybe it should=
 be
> > able to do both, just like the dbus daemon itself. If bluetoothd contai=
ns a
> > metaserver eventually it should be possible to have it launch applicati=
ons
> > with a GUI, like kbluetoothd is doing now. But we can=B4t start system =
services
> > on demand, even though this can be desirable too.
>=20
> It will be root only, because otherwise it can't listen for kernel
> events. We also need one central daemon to deal with all the stuff and
> so a session version makes no sense. However there is also no need it,
> because it will communicate only over D-Bus and this can be made session
> aware. The D-Bus also have somekind of activation mechanism that should
> make it possible to start application, but I never looked at that. Right
> now there are other things with higher priority.
>=20
> Regards
>=20
> Marcel
>=20
[Claudio Takahasi]
Basically two bus type are available: system and session.
System bus is not able to start applications with user interfaces
because the dbus-daemon is running with root permissions.
I already implemented D-Bus service for pand including daemon
initiation and it is working fine.
Use DBUS for request BlueZ services will be nice because it's=20
possible handle security issues and concurrency.
DBus signal can be used to notify all D-BUS registered applications about
new devices, new services, connection problems, ...

D-Bus is under development and some changes can occur, but it's
possible develop some workarround to make the application compliant
with Dbus 0.34, 0.33 and 0.23.

Regarding MIME types and Gnome VFS  I am not familiar enough to
send comments.... sorry.


Regards,
Claudio

>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Marcel Holtmann]

Hi Claudio,

> Basically two bus type are available: system and session.
> System bus is not able to start applications with user interfaces
> because the dbus-daemon is running with root permissions.

why is activation not working with the system bus. However we might have
to use system and session bus at the same time.

> Use DBUS for request BlueZ services will be nice because it's 
> possible handle security issues and concurrency.

This is the basic idea and it is the reason for putting everything
inside bluetoothd and designing a new kernel interface.

> DBus signal can be used to notify all D-BUS registered applications about
> new devices, new services, connection problems, ...

The new InquiryResult and RemoteName signals are implemented in hcid for
testing. Start "dbus-monitor --system" and call "hcitool scan".

> D-Bus is under development and some changes can occur, but it's
> possible develop some workarround to make the application compliant
> with Dbus 0.34, 0.33 and 0.23.

I already did that, but I am not very happy with it. I actually really
like to see the 1.0 release of their API.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Claudio Takahasi]

Hi Marcel,

On 7/8/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>=20
> > Basically two bus type are available: system and session.
> > System bus is not able to start applications with user interfaces
> > because the dbus-daemon is running with root permissions.
>=20
> why is activation not working with the system bus. However we might have
> to use system and session bus at the same time.
No, It is working fine. I tested in D-Bus 0.23, 0.33 and 0.34.
I developed the D-Bus service for pand and it's possible start this daemon
using system Bus because there no graphical interface involved.
System bus is intended to be common for all user sessions and=20
session bus is restricted to the current user session.
If you need start a program that has graphical interface the activate reque=
st
should be sent to the session bus instance.

>=20
> > Use DBUS for request BlueZ services will be nice because it's
> > possible handle security issues and concurrency.
>=20
> This is the basic idea and it is the reason for putting everything
> inside bluetoothd and designing a new kernel interface.

I see a new repository in the CVS(Bluehood).  I think that this
daemon will be the metaserver, is that correct?

>=20
> > DBus signal can be used to notify all D-BUS registered applications abo=
ut
> > new devices, new services, connection problems, ...
>=20
> The new InquiryResult and RemoteName signals are implemented in hcid for
> testing. Start "dbus-monitor --system" and call "hcitool scan".
I didn't find  this code in the bluez-utils-2.18 code. Where is it? Could
you send me the CVS branch or the code?
I found references in the kbluetoothd(neighbourmonitor.cpp), but there is n=
o=20
D-Bus messages involved.

>=20
> > D-Bus is under development and some changes can occur, but it's
> > possible develop some workarround to make the application compliant
> > with Dbus 0.34, 0.33 and 0.23.
>=20
> I already did that, but I am not very happy with it. I actually really
> like to see the 1.0 release of their API.
>=20
> Regards
>=20
> Marcel
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Marcel Holtmann]

Hi Claudio,

> I see a new repository in the CVS(Bluehood).  I think that this
> daemon will be the metaserver, is that correct?

actually that is quite old and has nothing to do with it. The new
bluetoothd will be inside utils/daemon/.

> > The new InquiryResult and RemoteName signals are implemented in hcid for
> > testing. Start "dbus-monitor --system" and call "hcitool scan".
> I didn't find  this code in the bluez-utils-2.18 code. Where is it? Could
> you send me the CVS branch or the code?
> I found references in the kbluetoothd(neighbourmonitor.cpp), but there is no 
> D-Bus messages involved.

You are mixing things here. The KDE Bluetooth stuff has nothing to do
with it at the moment. The code is inside the CVS and will be part of
the 2.19 release.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Claudio Takahasi]

Hi Marcel,

On 7/8/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>=20
> > I see a new repository in the CVS(Bluehood).  I think that this
> > daemon will be the metaserver, is that correct?
>=20
> actually that is quite old and has nothing to do with it. The new
> bluetoothd will be inside utils/daemon/.
[Claudio Takahasi]
Which D-Bus services will be provided by bluetoothd?=20
Please fix me if it is wrong or add more details to clarify=20
my clouds.
- periodic inquiry?
- service discovery? Currenlty, All daemons(dund, pand, hidd )=20
 have search option. In my opinion a parametrized search
 should be provided only by bluetoothd
- signal lost notifications?
- link configuration?
- adapter status: enable/disable authentication, encryption, pscan, iscan ?


Are there plans to implement D-Bus services for=20
the others bluez-utils daemons?

Regards,
Claudio.

>=20
> > > The new InquiryResult and RemoteName signals are implemented in hcid =
for
> > > testing. Start "dbus-monitor --system" and call "hcitool scan".
> > I didn't find  this code in the bluez-utils-2.18 code. Where is it? Cou=
ld
> > you send me the CVS branch or the code?
> > I found references in the kbluetoothd(neighbourmonitor.cpp), but there =
is no
> > D-Bus messages involved.
>=20
> You are mixing things here. The KDE Bluetooth stuff has nothing to do
> with it at the moment. The code is inside the CVS and will be part of
> the 2.19 release.
>=20
> Regards
>=20
> Marcel
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Marcel Holtmann]

Hi Claudio,

> Which D-Bus services will be provided by bluetoothd? 
> Please fix me if it is wrong or add more details to clarify 
> my clouds.
> - periodic inquiry?
> - service discovery? Currenlty, All daemons(dund, pand, hidd ) 
>  have search option. In my opinion a parametrized search
>  should be provided only by bluetoothd
> - signal lost notifications?
> - link configuration?
> - adapter status: enable/disable authentication, encryption, pscan, iscan ?

actually my idea is to do everthing inside bluetoothd and then send
signals via D-Bus and provides methods for settings etc.

> Are there plans to implement D-Bus services for 
> the others bluez-utils daemons?

If this works out, then I like to integrate HID, PAN and CIP into it and
provide methods for it.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Fred Schaettgen]

On Friday, 8. July 2005 08:38, Marcel Holtmann wrote:
=2E..
> I don't see the advantage of having two different VFS modules for device
> and service discovery. And since both are only presenting stuff that can
> be retrieved from bluetoothd they won't be highly complex.

This one VFS module is just doing two different things, so it cleaner to=20
separate it. If you want those modules to show virtual folder for various=20
purposes (recently seen devices, paired devices, hierarchical browse groups=
,=20
whatever), then you have a clean namespace available for both parts.
It=B4s no big advantage, but it=B4s not more difficult either. And it=B4s t=
he status=20
quo for kdebluetooth.

> Since Nautilus is supporting "Open with" it might be possible to assign
> multiple applications to one MIME type. This also means that we need
> different MIME types for each service/profile.

AFAIK =A8Open with...=A8 is just good for opening a file with a given mimet=
ype=20
with another application that supports the same mimetype (like different te=
xt=20
editors).

=2E..
> It was a long time ago when I read the RFC 2046. However after looking
> through it, I think we must use the application main type with the x-
> subtype. What about stuff like this:
>
> 	application/x-bt.device
> 	application/x-bt.service
>
> 	application/x-bt.handsfree
>
> On the other hand I remembered that the BIP already needed special MIME
> types and it seems they are using x-bt/img-listing and so on for it.

I really don=B4t care much.
But I wonder if this isn=B4t actually an abuse of mimetypes. Aren=B4t mimet=
ypes=20
supposed to declare the format of a file? Yet we are not talking about file=
=20
contents at all here. Instead we associate a mimetype with a certain URL=20
format.
At the moment, an item with the mimetype =A8bluetooth/obex-push-profile=A8 =
can=20
only live inside the sdp kioslave.
Maybe a more correct way would in fact be to have a helper application=20
associated with the type application/x-bt.service, which gets the informati=
on=20
what device to connect to not from the URL, but from the URL contents.=20
application/x-bt.service could simply be a file that contains the whole=20
service record as xml, similar to the service record files for the=20
metaserver. The applications would have to parse this xml file, which isn=
=B4t=20
very lightweight, but it gives all available information and we don=B4t hav=
e to=20
worry how to squezze everything into an URL.

The only drawback I see here is that the user can=B4t change the=20
service<->application association with the UI of the desktop. This UI is=20
about associating mimetypes with applications, but we would have our own=20
UID<->application mapping then. It=B4s more work for us, but it appears to =
be a=20
better and more flexible design.

Instead of handling a given mimetype, application would have to install a=20
bluetooth specific registration file instead. We could even let the helper=
=20
application (let=B4s call it service dispatcher) open the connection and pa=
ss a=20
file descriptor to the application, just the the metaserver, but for outgoi=
ng=20
connection. This could be nice for very simple applications. =A8Real=A8=20
application should get the bdaddr and rfcomm channel etc. from the service=
=20
dispatcher though, so they can reconnect themselves.

=2E..
> It will be root only, because otherwise it can't listen for kernel
> events. We also need one central daemon to deal with all the stuff and
> so a session version makes no sense. However there is also no need it,
> because it will communicate only over D-Bus and this can be made session
> aware. The D-Bus also have somekind of activation mechanism that should
> make it possible to start application, but I never looked at that. Right
> now there are other things with higher priority.

Oh, I didn=B4t know that. The pin helper isn=B4t started via dbus currently=
, or is=20
it?

=46red

=2D-=20
=46red Schaettgen
bluez-devel@schaettgen.de


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Marcel Holtmann]

Hi Fred,

> > I don't see the advantage of having two different VFS modules for dev=
ice
> > and service discovery. And since both are only presenting stuff that =
can
> > be retrieved from bluetoothd they won't be highly complex.
>=20
> This one VFS module is just doing two different things, so it cleaner t=
o=20
> separate it. If you want those modules to show virtual folder for vario=
us=20
> purposes (recently seen devices, paired devices, hierarchical browse gr=
oups,=20
> whatever), then you have a clean namespace available for both parts.
> It=B4s no big advantage, but it=B4s not more difficult either. And it=B4=
s the status=20
> quo for kdebluetooth.

actually my plan was not to do that much inside the VFS module. My plan
is to leave some stuff for other people, because I am not really an UI
programmer ;)

> > Since Nautilus is supporting "Open with" it might be possible to assi=
gn
> > multiple applications to one MIME type. This also means that we need
> > different MIME types for each service/profile.
>=20
> AFAIK =A8Open with...=A8 is just good for opening a file with a given m=
imetype=20
> with another application that supports the same mimetype (like differen=
t text=20
> editors).

What is the difference. You have multiple applications dealing with the
MIME type for handsfree and one is default. I think that is what you was
asking for.

> > It was a long time ago when I read the RFC 2046. However after lookin=
g
> > through it, I think we must use the application main type with the x-
> > subtype. What about stuff like this:
> >
> > 	application/x-bt.device
> > 	application/x-bt.service
> >
> > 	application/x-bt.handsfree
> >
> > On the other hand I remembered that the BIP already needed special MI=
ME
> > types and it seems they are using x-bt/img-listing and so on for it.
>=20
> I really don=B4t care much.

I actually like to get opinion on it.

> But I wonder if this isn=B4t actually an abuse of mimetypes. Aren=B4t m=
imetypes=20
> supposed to declare the format of a file? Yet we are not talking about =
file=20
> contents at all here. Instead we associate a mimetype with a certain UR=
L=20
> format.

In general yes, but they always have been misused.

> At the moment, an item with the mimetype =A8bluetooth/obex-push-profile=
=A8 can=20
> only live inside the sdp kioslave.
> Maybe a more correct way would in fact be to have a helper application=20
> associated with the type application/x-bt.service, which gets the infor=
mation=20
> what device to connect to not from the URL, but from the URL contents.=20
> application/x-bt.service could simply be a file that contains the whole=
=20
> service record as xml, similar to the service record files for the=20
> metaserver. The applications would have to parse this xml file, which i=
sn=B4t=20
> very lightweight, but it gives all available information and we don=B4t=
 have to=20
> worry how to squezze everything into an URL.

I am not really happy with adding somekind of XML overhead.

> The only drawback I see here is that the user can=B4t change the=20
> service<->application association with the UI of the desktop. This UI i=
s=20
> about associating mimetypes with applications, but we would have our ow=
n=20
> UID<->application mapping then. It=B4s more work for us, but it appears=
 to be a=20
> better and more flexible design.
>=20
> Instead of handling a given mimetype, application would have to install=
 a=20
> bluetooth specific registration file instead. We could even let the hel=
per=20
> application (let=B4s call it service dispatcher) open the connection an=
d pass a=20
> file descriptor to the application, just the the metaserver, but for ou=
tgoing=20
> connection. This could be nice for very simple applications. =A8Real=A8=
=20
> application should get the bdaddr and rfcomm channel etc. from the serv=
ice=20
> dispatcher though, so they can reconnect themselves.

Too far in the future for me, because I am still working on the basis.

> > It will be root only, because otherwise it can't listen for kernel
> > events. We also need one central daemon to deal with all the stuff an=
d
> > so a session version makes no sense. However there is also no need it=
,
> > because it will communicate only over D-Bus and this can be made sess=
ion
> > aware. The D-Bus also have somekind of activation mechanism that shou=
ld
> > make it possible to start application, but I never looked at that. Ri=
ght
> > now there are other things with higher priority.
>=20
> Oh, I didn=B4t know that. The pin helper isn=B4t started via dbus curre=
ntly, or is=20
> it?

The current PIN helper can't do that, because it is D-Bus 0.23 based and
back then the activation service was no available. I am not fully happy
with switching over to D-Bus 0.34 at the moment. This might leave some
distributions behind and they may change parts of the API anyway.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Fred Schaettgen]

[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]

On Friday, 8. July 2005 16:43, Marcel Holtmann wrote:
...
> > But I wonder if this isn´t actually an abuse of mimetypes. Aren´t
> > mimetypes supposed to declare the format of a file? Yet we are not
> > talking about file contents at all here. Instead we associate a mimetype
> > with a certain URL format.
>
> In general yes, but they always have been misused.



> > At the moment, an item with the mimetype ¨bluetooth/obex-push-profile¨
> > can only live inside the sdp kioslave.
> > Maybe a more correct way would in fact be to have a helper application
> > associated with the type application/x-bt.service, which gets the
> > information what device to connect to not from the URL, but from the URL
> > contents. application/x-bt.service could simply be a file that contains
> > the whole service record as xml, similar to the service record files for
> > the metaserver. The applications would have to parse this xml file, which
> > isn´t very lightweight, but it gives all available information and we
> > don´t have to worry how to squezze everything into an URL.
>
> I am not really happy with adding somekind of XML overhead.

But it´s the most natural format for a hierarchical data structure like the 
service records. The computational overhead would be neglectable and it only 
has to be implemented in the service dispatcher, not in each application 
started by it. We can put everything we know in the xml structure without 
much effort. Extending the url format might become more troublesome at some 
point. 
We could also go without the service dispatcher and still use distinct 
mimetypes for each service, but let the application read the needed 
information from the data the url points to and not from the URL itself.
We didn´t have to standardize on a URL format then, but just on the mimetypes 
and the service description format, be it xml or anything else. 
In KDE it would allow for a kfile plugin which displays additional properties 
of services in konqueror besides the name. 
Or we could do both - putting just the most relevant information into the URL 
(bdaddr+channel) and the complete service record, device adress + name and 
everything else we know about a service into the file contents as xml similar 
to sdp registration files we use (see attachment).

Fred

-- 
Fred Schaettgen
bluez-devel@schaettgen.de

[-- Attachment #2: kbluetoothd_kbtobexsrv.sdp.xml --]
[-- Type: text/xml, Size: 1284 bytes --]

<sdprecord>
<attributes>

<!-- Service name -->
<attribute id='0x0100'>
<str>Obex Push Server</str>
</attribute>

<!-- Service description -->
<attribute id='0x0101'>
<str>KDE OBEX Object Push Service</str>
</attribute>

<!-- Supported formats list -->
<attribute id='0x0303'>
<seq>
<uint val='0xFF' size='8'/><!-- anything  -->
<uint val='0x01' size='8'/><!-- vCard 2.1 -->
<uint val='0x02' size='8'/><!-- vCard 3.0 -->
<uint val='0x03' size='8'/><!-- vCal  1.0 -->
<uint val='0x04' size='8'/><!-- iCal  2.0 -->
<uint val='0x05' size='8'/><!-- vNotes    -->
<uint val='0x06' size='8'/><!-- vMessage  -->
</seq>
</attribute>

<!-- Service class ID list -->
<attribute id='0x0001'>
<seq>
<uuid val='0x1105' size='16'/>
</seq>
</attribute>

<!-- Protocol descriptor list -->
<attribute id='0x0004'>
<seq>
<seq><uuid val='256' size='16'/></seq>
<seq><uuid val='3' size='16'/>
<uint valref='rfcommchannel' size='8'/></seq>
<seq><uuid val='0x0008' size='16'/></seq>
</seq>
</attribute>

<!-- Browse group list-->
<attribute id='0x0005'>
<seq>
<uuid val='0x1002' size='16'/>
</seq>
</attribute>

<!-- Bluetooth profile descriptor list -->
<attribute id='0x0009'>
<seq>
<seq><uuid val='0x1105' size='16'/>
<uint val='0x0100' size='16'/></seq>
</seq>
</attribute>

</attributes>
</sdprecord>

Re: [Bluez-devel] Bluetooth MIME types and URIs

[Marcel Holtmann]

Hi Fred,

> > > At the moment, an item with the mimetype =A8bluetooth/obex-push-pro=
file=A8
> > > can only live inside the sdp kioslave.
> > > Maybe a more correct way would in fact be to have a helper applicat=
ion
> > > associated with the type application/x-bt.service, which gets the
> > > information what device to connect to not from the URL, but from th=
e URL
> > > contents. application/x-bt.service could simply be a file that cont=
ains
> > > the whole service record as xml, similar to the service record file=
s for
> > > the metaserver. The applications would have to parse this xml file,=
 which
> > > isn=B4t very lightweight, but it gives all available information an=
d we
> > > don=B4t have to worry how to squezze everything into an URL.
> >
> > I am not really happy with adding somekind of XML overhead.
>=20
> But it=B4s the most natural format for a hierarchical data structure li=
ke the=20
> service records. The computational overhead would be neglectable and it=
 only=20
> has to be implemented in the service dispatcher, not in each applicatio=
n=20
> started by it. We can put everything we know in the xml structure witho=
ut=20
> much effort. Extending the url format might become more troublesome at =
some=20
> point.=20
> We could also go without the service dispatcher and still use distinct=20
> mimetypes for each service, but let the application read the needed=20
> information from the data the url points to and not from the URL itself.
> We didn=B4t have to standardize on a URL format then, but just on the m=
imetypes=20
> and the service description format, be it xml or anything else.=20
> In KDE it would allow for a kfile plugin which displays additional prop=
erties=20
> of services in konqueror besides the name.=20
> Or we could do both - putting just the most relevant information into t=
he URL=20
> (bdaddr+channel) and the complete service record, device adress + name =
and=20
> everything else we know about a service into the file contents as xml s=
imilar=20
> to sdp registration files we use (see attachment).

actually right now, I don't tend in either direction.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel