Reg bringing up libqmi

[Aleksander Morgado]

>>> If you really want to use QMI properly, then only an integration into a
>>> real telephony stack makes sense. I never considered a standalone QMI
>>> library a good idea. Same as nobody really has a standalone library for
>>> just handling AT commands. 
>>
>> A standalone QMI library itself, and actually every library, is stupid,
>> of course, unless a connection manager or other application uses it :)
>> libqmi is used by both qmicli/qmi-network and ModemManager (and possibly
>> Python-based connection managers soon through GObject introspection).
>>
>> Also, libqmi is not only about reusing code, it's about making it easier
>> to use the protocol by hiding all the logic to handle
>> request/responses/indications. The libmbim I'm writing these days for
>> MBIM goes even further and handles transparently all message
>> fragmentation requirements, which is nice. Why does everyone have to
>> write its own QMI handling code within the telephony stack in order to
>> "use QMI properly"?
> 
> So QMI and MBIM should be libraries, but AT commands are not. That is
> kinda funny. But then again parsing AT commands with regular expressions
> was never a good idea to begin with in my book ;)
> 

Well, QMI and MBIM are kind of similar, with properly defined message
types and such. I wouldn't compare them to AT in any case, where each
vendor decided to use it in its own way.

Also, I'm not saying that QMI and MBIM should be libraries, or that
libqmi-glib is the only way to go. I just prefer to have them as
reusable libraries than rewriting the same code in multiple
applications. You of course don't have to write them as libraries
because I do say so. Still, you say that everyone should write its own
QMI handling code within the application in order to "use QMI properly".
That's what I don't get.


>> Also, I very much prefer a code generator giving me all needed sources
>> to parse and create really complex messages with TLVs including arrays
>> of structs with other arrays inside for example, than writing a custom
>> parsing for each new such TLV I find... e.g.
>>
>> http://cgit.freedesktop.org/libqmi/tree/data/qmi-service-dms.json#n971
>>
>> Of course you still need to then integrate the logic in your own
>> connection manager, but at least I don't need to write the parsing code
>> for that message.
> 
> If you think DMS is complicated, then you might look into UIM. That is
> the one that Qualcomm really screwed up. And if you ever move away from
> a simple Internet only connection manager into a real telephony stack,
> then UIM is what you need. The Gobi 2000 cards without UIM service are
> actually painful to deal with. Their exposed services are not giving you
> enough access to low-level details.
> 
> UIM service is the one where Qualcomm engineers should have taken a
> lesson in what TLVs are really for and how you could use them, but they
> decided not to.

Good to know.


> 
> Anyway if your basic message structure is TLV based, then I never
> understand why you would pre-parse everything into other memory
> locations and waste the memory. Especially if you do not know what the
> application requires in the end. That is why a like the context specific
> parsing of the messages. I can take the pieces I need and ignore the
> rest. Even if I know how to parse them. Which means I have less memory
> to allocate for each message that I need to parse.
> 

Actually, I don't think that modifying libqmi to avoid preparsing
everything would be a great deal, it was just convenient initially. We
can of course still improve it to avoid doing the preparsing and only
parse TLVs as we need them. I actually do that in libmbim, where the
fields are read directly from the raw message binary stream.


>>> So for oFono its all fully integrated and
>>> that helps a lot when you reach the point of having to deal with the SIM
>>> filesystem, SIM Toolkit or SMS.
>>
>> I understand that if you're targeting custom embedded systems you don't
>> want a generic implementation and you may want your own, e.g. only
>> implementing the messages you really need. That's fine, and wise. Now, I
>> don't know how exactly that helps in dealing with e.g. SMS. How does a
>> fully integrated custom implementation help with that? Just wondering.
> 
> The SMS part is still sort of simple in QMI, but has some nasty bits
> with the message routing when you want to run it in a telephony stack.
> Just in case anybody cares, but then again ModemManager still thinks
> that managing messages on the SIM card is a good idea ;)
> 
> Look into UIM and CAT services if you want to see something nasty.
> 

I'm sure there are messages difficult to use; but still, if I can skip
writing the message parsing/creating/sending/receiving code, I
personally prefer that. I'll have 1 problem instead of 2 :)


-- 
Aleksander