[Mono-list] [ANNOUNCE] Monotooth 0.1.0 Beta released

Aleksi Suomalainen asuomala at hytti.uku.fi
Fri Aug 3 06:37:51 EDT 2007

Andreas Färber wrote:
> Hi,
>>> Independent of the underlying implementation it would be more handy 
>>> if you could provide front-end classes like LocalDevice that wrap any 
>>> internal platform decisions, so that e.g. the local device's 
>>> (default) BDADDR can be accessed via LocalDevice.Address (JSR-82 
>>> style) instead of having to go through the full-blown factory pattern 
>>> first - the developer cannot really chose an implementation to use on 
>>> a given platform as in the classic widget factory example.
>> This could be done at some point but by now I'll stick to this way :). 
>> One may use a little longer method chain to achieve this.
> That's what I'm trying to avoid. So you would be opposed to such a 
> contribution?

I'm basically not against it, but this way of getting the local device 
address would break the design a little. I'll see what can be done :).

>>> Also, I see on Linux you are handling the inquiry via a native 
>>> library and BlueZ's hci_inquiry function - I have recently found 
>>> their D-Bus interface to be much more powerful (inquiry provides 
>>> up-to-date RSSI), and using dbus-sharp would reduce the need for 
>>> native code in that area. I have some example code I could share.
>> Good idea, I would love to see this approach. The reason I'm using the 
>> native library->bluez way is the marshaling problem, since 
>> hci_inquiry() takes a double struct pointer.
> You are aware of the ref keyword, MarshalAs attribute and the 
> marshalling functions? It should be possible to replace virtually all 
> native code at the cost of typing in all relevant constants and possibly 
> using overloads. And for the socket stuff System.Net.Sockets.Socket 
> might be used, feeding it the constants as integers.
Yes, I'm very aware of the ref keyword and all the others. The problem 
with ref keyword is correctly implementing pointer arithmetics, see 
The main point of my current work is to try to avoid the use of my 
custom library. If I get the hci_inquiry function to work via Marshaling 
, then I will definitely add it to code, but now it is very difficult.

The problem with System.Net.Sockets.Socket (and calling the 
socket()/bind()/connect() from BSD socket interface) is that they use 
special casts to create the connection. The socket() part is not a 
problem, I can use constants as you said. The problem is 
bind()/connect() part of the connections: for example, connect(socket, 
(struct sockaddr*)address, length). The cast is the problem, since I 
have tried it already via creating my own structure in Mono and passing 
it as a parameter to bind(). It failed miserably, since the Marshaling 
failed to cast it to a form that bind() could understand.

>>> Finally, would you be interested in extending platform support to Mac 
>>> OS X in future versions?
>> Well I don't have a Mac OS X machine yet but this could be done with 
>> volunteer workforce if Mac OS X has a good bluetooth interface.
> I wouldn't call it good compared to BlueZ but I am running OS X so don't 
> have a choice and would look into it either way some time in the future. 
> For me the point is, I'd need Bluetooth functionality across .NET CF 
> 1.0, .NET 3.0 and Mono/OSX - none of these are currently supported in 
> Monotooth, so my options are add support for them in Monotooth in an 
> easy-to-use and 1.1-profile managed-only way I can directly use them or 
> create a wrapper around SDF/Monotooth/mine that I could use from my code 
> or create my own specialised library for what I need only. I'd prefer 
> sharing such code with a community but would be okay with creating my 
> own subset if for example you've already chosen to use generics or don't 
> want to extend your library in such ways.
The extensions will not be a problem, so feel free to create your code 
and publish it. I will integrate it to Monotooth quite surely, since the 
aim of my library is to be as cross-platform as possible. In case 
someone else is interested too, just try stick to the abstract factory 
pattern, implement it the OS X way and submit a patch to me.

> Regards,
> Andreas

Aleksi Suomalainen
Pyöräkatu 9 b 52
70600 Kuopio
asuomala at hytti.uku.fi

More information about the Mono-list mailing list