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

[Aleksander Morgado]

Hey Dan,

>>
>>>> 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.
>>>>
>>>> Comments?
>>> Hi Aleksander,
>>> 	That's good news. I started looking at your libqmi-glib a few weeks ago
>>> so that I might use it for creating python bindings. It's a free time only
>>> project at the moment for me, so I didn't get too far yet, but I'm hopeful of
>>> getting to it soon. If anyone else wants to step up and do this, feel free, it
>>> might be quicker :-)
>>>
>>
>> It shouldn't be difficult to include introspection in the library
>> through gobject introspection, magic keywords in gtk-doc comments and
>> all that... but I have no experience on that myself.
>
> I do, I'm happy to update it.  Note that GObject Introspection can't
> handle some deeper forms of introspection, like hash tables in hash
> tables and stuff like that, because GHashTable can't introspect it's
> value contents.  To avoid that, you either return a GVariant, or custom
> structures/lightweight objects with accessor functions that you can
> introspect.
>

The generated code doesn't have any hash table or GVariants; only custom 
lightweight structs.

For each request/response, 'input' and 'output' bundles with their own 
ref()/unref(). The bundles then have getters() and setters() for each of 
the TLV expected in the message. If new TLVs are added to a 
request/response in the future, we'll just need to add new getter/setter 
to the corresponding bundle.

Each of the TLV is represented as a struct with the contents of the TLV, 
so I'm assuming here that existing TLVs won't change. The members of the 
structs are more or less basic types (guintX, gchar *, GArray *, 
QmiSomething...). The TLVs themselves are owned by the bundle; so the 
user shouldn't mess with the TLV structs returned by the getters. When 
setting a TLV in an input bundle, the bundle will make a deep-copy of 
the passed TLV. So getters and setters of the TLVs in the bundles are 
always transfer-none.

I believe this logic can be refined a bit more still, so comments 
appreciated. Also, if the logic is not suitable for easy introspection, 
I'm happy to update it.

-- 
Aleksander