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

[Dan Williams]

On Mon, 2012-07-02 at 10:18 +0200, Aleksander Morgado wrote:
> Hey Marcel,
> 
> > 
> >>> 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.
> > 
> > I am still failing to see what this all buys you. You still need to
> > understand what message input and output is available/required. You are
> > just getting fancy accessor methods. And these come at the price of a
> > larger binary size. If you look at QMI as something besides DMS and WDS,
> > it is pretty large API.
> > 
> 
> Not only fancy accessor methods. With this library, users do not need
> know message/tlv id enums (neither know nor implement them); users do
> not need to analyze and write packed structs to match input/output TLVs
> themselves; users do not need to care of parsing arrays or
> variable-length structs; users do not need to define enums themselves...
>  Users instead will get all the raw protocol stuff already 'digested'
> into a set of new types and methods (hopefully well documented at some
> point), with built-in GError-based error reporting and built-in GIO-like
> async method support. Of course, if you prefer to analyze and write
> support for the protocol yourself, this library buys you nothing.
> 
> > And a small side note; so for QMI it has to be a library that is suppose
> > to do everything. For AT commands it is then fine to redo things over
> > and over again and use resource intensive regular expressions.
> > 
> 
> You said that, not me :-)
> 
> > How many users of this library are you actually expecting? Since the QMI
> > device exposed by the kernel can only be opened by one user at a time.
> > 
> 
> Well, not everyone in the world is using the same connection manager.
> This library is just trying to provide a common way to handle the
> protocol for every connection manager interested, either directly in C
> (e.g. ModemManager), with python via introspection (e.g. Wader), or even
> with the 'qmicli' utility in shell scripts (e.g. the qmi4g protocol
> handler in OpenWRT).

There's clearly use for a QMI library that does most of the generic
things people need, accounts for the firmware variance, and (as a
fallback) possibly allows custom QMI request/responses from clients
without structured functions until those can be added to the library.
It's pointless to have people keep rewriting this code, so doing it once
in a flexible manner is a useful thing to do.  The answer clearly is not
opencoding it in everything that wants to talk QMI.

Dan