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

[Andreas Färber]

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.

>>>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DBusInquiry.cs
Type: application/octet-stream
Size: 1627 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-list/attachments/20070803/0c601fea/attachment.obj 
-------------- next part --------------

> 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.

> 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.

That would be really great!

Andreas