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

[Marcel Holtmann]

Hi Dan,

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

as I said, I am still failing to see what this all gives you. The logic
has to be repeating anyway. You need to know what you are doing with
these messages. QMI is heavily context oriented. So you don't have to
deal with TLV constants and have to know the accessor functions instead.
Same thing just a bit different.

Seriously, how many different users of libqmi-glib are you expecting?

Regards

Marcel