[RFC] libqmi without glib2 and qmicli JSON output

[Aleksander Morgado]

>>
>> Some years ago I started a "libembim", introducing a glib-less API
>> equivalent to libmbim, but didn't finish it and I spent quite some
>> time with it... Got the branch somewhere.
>>
>> All that said, yes, I wouldn't mind to have a glib2-less libqmi, but
>> leaving libqmi-glib as it is now. i.e. A new 'libeqmi" (e for
>> embedded) could be written.
>>
> uqmi uses a lot of libubox for this stuff [which has uloop for
> main-loop and some other stuff ] ;
> uqmi actually copied libqmi stuff and re-did some build stuff, and did
> the linking to libubox events/stuff
> what i don't like about uqmi is the fact that CLI params are different
> that qmicli
> also, it's not as maintained as libqmi [since it's secondary effort of
> OpenWrt/LEDE]
> while i can alloc time to make that stable/work for me, mid-to-long
> term it's a parallel effort
>
> libeqmi sounds very reasonable, if maybe we can make it an official
> element of libqmi ;
> so maybe have  libeqmi side-by-side with libqmi-glib ; or another repo
> ? [ both work for me ]
>

side-by-side would be fine.

> for libeqmi I would be tempted to use libubox, because it's an
> external lib of OpenWrt/LEDE
> that just wraps epoll and some other timers/events in a neat/easy way;
> i don't mind re-implementing a new epoll loop ; will see;
>

Oh please, no. That would make it openwrt/lede-only... the target
should be something generic that can be used anywhere, not just in
openwrt/lede. If you want something that is only for openwrt/lede, I'd
suggest to directly try to improve uqmi :)

>>> I agree we can't get rid of glib2 completely ; for OpenWrt/LEDE we
>>> have to build a host glib2 so that I can convert the .json definitions
>>> to C code [and that is perfectly fine].
>>> But for the target build [ that gets installed on the device ] I would
>>> prefer to not install glib2.
>>> And sure, maybe it's a futile effort, but I'd still like to try.
>>>
>>
>> There's no need for host glib2 to convert the JSON definitions to C
>> code, this is just a python program doing it.
>
> I think I noticed some Python stuff/scripts but I needed to define
>    GLIB_MKENUMS=$(STAGING_DIR)/host/bin/glib-mkenums
> I did not dig too deep to be sure if this can be non-needed.
>

That is just part of libqmi-glib, not part of the code generator.

>>> 3. The point (2) - qmicli JSON output
>>> Some OpenWrt/LEDE scripts/commands output JSON.
>>> And there is a very neat way [in the eco-system] to work with JSON in shell.
>>> I would also like to output JSON output [of course, me doing the work].
>>>
>>> Parsing JSON in OpenWrt/LEDE is way nicer than running sed,awk,grep
>>> commands to get the value I want.
>>> Especially when output is verbose, and I want 3 values of 20.
>>>
>>> Is this [also] something that's reasonable ?
>>>
>>
>> Oh, this is orthogonal to the no-glib2 issue. I'd love to have
>> something like this actually, and I believe there are patches out
>> there (in github?) from some other dev that already started to do
>> that. Same for mmcli and mbimcli outputs, if you're up to it :)
>
> interesting; will check it out
> if you remember where it is, please point me
>
> if not, i can try to find it or implement it from scratch
>

Didn't find it after a quick search, sorry.

-- 
Aleksander
https://aleksander.es