Moving libqmi-glib to fd.o's libqmi repo

[Aleksander Morgado]

Hey,

> 
>>> I looked deeply into all areas of QMI services. Trying to create a fully
>>> bloated library with API support for all services is a waste of time. At
>>> least for oFono it is useless. The problem is that QMI itself is deeply
>>> service context sensitive and there is no point in creating another
>>> abstraction on top of it. I decided to just put the service specific
>>> handling directly into the oFono drivers. Have a look at the code for
>>> yourself, it worked out super nicely for us.
>>
>> Sure it did, but we really want to have a library here, instead of 
>> having everyone implement the message-specific logic over and over.
>>
>>>
>>> There are also deprecated QMI commands and different versions of certain
>>> services. To handle them properly, you need to understand the service
>>> itself and know to handle it or fallback if needed. The first one where
>>> you will see this issue is NAS with the network selection and attach
>>> handling. Gobi 2000 differs clearly from newer cards here.
>>>
>>
>> The library is willing to support all QMI commands; it just provides a 
>> user-friendly interface to use those commands, assuming they are 
>> available. Given that we allow to run a version-info check during the 
>> QmiDevice opening, we may in the future tag each command with the 
>> specific version where it was introduced, and provide some more higher 
>> level logic which will use one command or the other based on the current 
>> available service versions. Out of the scope of the library right now 
>> anyway, clients should for now handle that themselves.
> 
> if you just implement all low-level service commands, then what is the
> difference of just having a simple generic way of dealing with QMI
> services like we do. It seems it is providing the same features, just
> with a more complex API on top of it. Not sure if that is actually
> helpful.
> 

Well, just representing the request/response of a message in JSON with
20-30 lines, I get the service-specific QmiClient extended with a
complete new async method ready to be used, including code to handle the
input and output TLVs it expects. It's really really handy.

See for example the PIN Change request/response:
https://gitorious.org/lanedo/libqmi-glib/commit/19316ab610241d33d5eacfb837f50d6f153130ee

And how qmicli uses the generated qmi_client_dms_change_pin():
https://gitorious.org/lanedo/libqmi-glib/commit/b9290d715048d75f0651bd0c55300fa1b07692ad

>>> And on that note, I think you will soon reach serious limitation with
>>> the code generation idea. The advanced QMI data structures are not
>>> funny. Have you actually looked into NAS or UIM services? You get some
>>> nice variable length strings and variable length structures embedded in
>>> the middle of other variable length structures. Or you have TLVs that
>>> extend the data structure, or replace others. In addition newer QMI
>>> services are heavily subscription based with their indications.
>>>
>>
>> Variable-length members on variable-length structs/arrays are no longer 
>> a problem since we do not create packed struct templates to cast the raw 
>> buffer, the generated code now reads the expected elements one by one.
> 
> You should check with UIM service and some of PDS service structs and
> see if that all still works for you. Some of them are seriously crazy.
> 
>> For the different TLVs, extending the data structure or replacing 
>> others, we're just fine as long as the existing TLVs are not modified 
>> (this is, the new ones get a new TLV ID).
> 
> In general they do. See the scan results where they added an extra TLV
> for the missing RAT information.
> 
> However with Voice service there are different between major versions.
> So I think the assumption can only be made per major version of a
> service.
> 

Hum... so a given TLV with a specific ID gets updated between versions
without updating the ID as well?

>> As for the indications, the idea is to implement signals on the 
>> QmiClients which will be emitted when the indications arrive, so that 
>> users of the library need just to connect to them once they have enabled 
>> the indications via request/response.
> 
> You do know that most indications vary on which TLVs they include
> depending on what is enabled or what happens in the system. Since
> individual TLVs can be enabled individually.
> 

The signals should just push the 'output' bundle of possible TLVs of the
indication, whatever they are, the client will need to get() each TLV
from the bundle afterwards. At least that's the idea, hope to have that
ready soon.

Cheers,

-- 
Aleksander