Subsurface-mobile Bluetooth download

[Jan Mulder]

On 05-06-17 17:49, Dirk Hohndel wrote:
> On Mon, Jun 05, 2017 at 05:40:10PM +0200, Jan Mulder wrote:
>> On 05-06-17 16:41, Dirk Hohndel wrote:
>>> We learned from HW that this should never be the case with production
>>> OSTC. Hmm. Not sure what to do here... that's a generic ID for the chip
>>> they used - not sure if it's smart to assume that's an OSTC. But maybe
>>> that's what we should do? Or we need another UI to pick the device...
>> I think we need another UI to pick the device anyhow (unfortunately). For
>> example, for divers that  that use more than one BT dive computer, or in the
>> special cases that automatically checking of a long list of paired BT
>> devices fails.
> I think I have an idea how to do that, actually... we could create a
> "virtual" vendor "Paired BT Devices" and then as "products" we could have
> the paired devices... I'll play with that idea.
>
> /D


Ok, I followed up on the forTomaz branch to see if the idea with a 
virtual vendor and a set of paired devices could work. I have things 
partly working (not commit ready yet). I see, however, a fundamental 
problem with this strategy. In order to do a correct dc_device_open, we 
need a real vendor/product pair, and that data is not coming from a 
paired BT device. In fact, when we could construct a real vendor/product 
pair from only BT discovery data, we wouldn't need a virtual vendor in 
the first place.

Obviously, we could construct logic to translate a BT name to a 
vendor/product pair and attach that data to virtual vendor/paired device 
(and basically we need this anyhow to do automatic discovery of DCs), 
but that still does not enable downloading from a paired BT device of 
which we could not determine the real vendor/product pair (but would 
enable downloading from more than one BT DC from one client).

Concluding, I am a bit stuck ...

--jan