<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, May 24, 2014 at 10:51 PM, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think there is a point in adding the limitation just due to 1<br>
service behaving that way.</blockquote><div> </div><div>I have a feeling that if one OEM does it there will be others who do it.</div><div>Even ignoring this one service we're going to run into this, on a smaller scale,</div>
<div>once OEMs start implementing GNSS over MBIM. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 Actually, if the service is going to<br>
transfer huge amounts of data within MBIM indications, it probably<br>
makes more sense to them to setup a specific DSS session for that,<br>
instead of overflowing the main MBIM communication channel.</blockquote><div> </div><div>Agreed and we did try to convince them of that and hopefully this will be</div><div>implemented in the future.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, what<br>
about other unknown services which may expect to have clients listen<br>
to the indications even when the service was not used in advance?.<br>
<div class=""><br></div></blockquote><div> </div><div>Yeah, I was pondering that too, but since the spec I was working with</div><div>specified that the indications were turned on and off I mistakenly assumed </div><div>
it was standard as part of the MBIM spec.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
</div>I'm not sure if that's true in MBIM. It is in QMI; i.e. a client can<br>
register to get notified about a given indication, and can unregister<br>
when it no longer wants them. In the case of MBIM; receiving<br>
indications is not something we can choose or not choose, I believe.<br>
So, by default we should forward all indications.<br></blockquote><div><br></div><div>Yeah, now that I went back to look at the spec, you're right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Another thing, though, is whether we want to include an additional<br>
private command in the proxy service to let clients register or<br>
unregister to some indications. If the client wants to get notified<br>
about only a subset of indications, we can setup a new open-flag to<br>
request that, so that it can then "subscribe" only to the indications<br>
that it wants. Given that this is to be handled by the proxy (i.e. the<br>
communication with the device will still handle all notifications), it<br>
can just be seen as an addon, same as the proxy is. The only problem<br>
with this approach is that then, we're kind of forcing standard<br>
clients to use this logic, so that they don't get bothered with<br>
indications they don't know of...<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div> </div><div>I was thinking about doing that too but limit the indication registration to only</div><div>non-standard services.   So standard clients won't require any change.</div>
<div>I would prefer this solution over forwarding all indications, purely for performance.</div><div>A mbim_device_register_custom_service() could be added which would then call</div><div>mbim_register_custom_service() and send the private command to the proxy.</div>
<div>Same would be done for unregister.</div><div><br></div><div>Thanks,</div><div><br></div><div>Greg</div><div><br></div></div></div></div>