[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 :).
> 
> I was thinking of a wrapper along these lines:
> 
> public class LocalDevice {
>     public static ILocalDevice Default {
>         return Factory.Create().GetDevice(); // you'll know better
>     }
> }
> 
> leading to an invocating like LocalDevice.Default.Address, hiding the 
> underlying complexity.
> This way it allows the use of multiple devices and leaves the factory 
> pattern untouched; an alternative or addition would be the adapter 
> pattern but that'll be much more complicated.
You are correct on this, the latest svn now has that piece of code and 
the next release will include documentation on this class.

>>>>> 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.
> 
> I know how to inquire with BlueZ. ;-) Yet I don't see where the pointer 
> arithmetic problem is in that piece of example code. If you want to use 
> HCI you can use Marshal.AllocHGlobal with Marshal.SizeOf to calculate 
> the size and offsets?
> 
> See attached for an alternative way to inquire, which can avoid waiting 
> 10 seconds for the first results using events and can supply the RSSI.
Thanks for this alternative way, I'll take a look on how to integrate 
this to my code as soon as possible. Although this would create 
dependencies to another library, this approach is by far much more 
handier :), thanks for sharing this.

>> 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.
> 
> Sockets are a C API so casts are unlikely to be the problem (it's a 
> pointer to a struct either way and is used because C does not have the 
> concept of inheritance). More likely is that the managed structure used 
> for marshalling was incorrect. I'll look into it. Having it managed 
> would be beneficial for using the code in a daemon.
Good, thanks.

PS. I have created a mailing list in sourceforge for monotooth, the 
mailing list will open in 6-24 hours and its address is:

monotooth-devel at lists.sourceforge.net

So this mailing list should be the primary list so that we won't mess up 
the mono-list :).

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