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

[Aleksander Morgado]

Hey Marcel,

>
>> I am going to prepare to move libqmi-glib from gitorious.org directly
>> into the libqmi repo at fd.o.
>>
>> In this process, I was going to rename it from libqmi-glib just to
>> libqmi, but don't have a strong feeling on this. If anyone is willing to
>> develop a glib/gobject/gio-free version of libqmi, just speak up and
>> I'll keep the -glib suffix. Anyone willing to do so can already benefit
>> from the codegen I guess, just modifying the codegen to generate
>> glib-free code. Actually, I may just leave the prefix anyway, in case
>> someone shows up in the future willing to do so.
>
> actually there is a libqmi in the Chromium tree:
>
> http://git.chromium.org/chromiumos/platform/libqmi.git
>

Yeah, know it, basic QMI handling in libqmi-glib comes from it.
I believe in Chromium they are now happy with the GObject/GIO version of 
the library, though.

> And we already have developed a GObject/GIO free version of QMI support
> for oFono.
>
> http://git.kernel.org/?p=network/ofono/ofono.git;a=blob;f=drivers/qmimodem/qmi.h;hb=HEAD
>
> However there is no real plan to turn this specific code into a real
> standalone library. It is just the basic QMI transport, control point
> and service discover handling. And it is tiny:
>
>   1938 drivers/qmimodem/qmi.c
>    152 drivers/qmimodem/qmi.h
>   2090 total
>
> Maintaining a separate project and library for that seems total
> overkill.

Still, given that you guys already have a GObject/GIO free version of 
the library, I'll keep the "-glib" prefix. Someone may want to work on a 
fully glib-free based version of the library from your sources in the 
future.

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

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

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

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.

Cheers!

-- 
Aleksander