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

[Aleksi Suomalainen]

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 
http://people.csail.mit.edu/albert/bluez-intro/c401.html#bzi-choosing. 
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
Regards,

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