[libvirt] [libvirt-glib] Correct namespace prefix for GVirConfig symbols

[Zeeshan Ali (Khattak)]

On Thu, Dec 22, 2011 at 5:17 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> On Thu, Dec 22, 2011 at 02:26:48AM +0200, Zeeshan Ali (Khattak) wrote:
>> On Thu, Dec 22, 2011 at 1:46 AM, Zeeshan Ali (Khattak)
>> <zeeshanak at gnome.org> wrote:
>> > On Thu, Dec 22, 2011 at 1:43 AM, Zeeshan Ali (Khattak)
>> > <zeeshanak at gnome.org> wrote:
>> >> From: "Zeeshan Ali (Khattak)" <zeeshanak at gnome.org>
>> >>
>> >> Breaks API and ABI on the fundamental level but lets fix this now while
>> >> we don't guarantee any API/ABI stability.
>> >
>> > Forgot to mention that this patch is on top of Christophe's ACK'ed but
>> > unmerged 'Add GVirConfigDomainSound' tree.
>>
>>   And seems my patch went over the limit so it got chopped. You can
>> find the patch here as well:
>> https://gitorious.org/~zeenix/libvirt/zeenix-libvirt-glib/commit/d5e5c64732baa091d5078c87aab64df4cdb9e08d
>
> For what it's worth, I don't think this patch improves the situation much
> if we can't express nested namespaces (ie put all the GVirConfigDomain*
> objects to a GVir::Config::Domain or GVirConfig::Domain namespace).

  The patch improves the situation as it makes the whole API very
consistent w.r.t what exactly is the namespace here. Curently that is
supposed to be GVirConfig, judging from GIR and Vala bindings. I also
agree that nested namespaces will be better. If we decide/manage to go
towards nested namespaces, this patch actually helps in that regard as
well since existing API is not consistent/correct for that purpose
either.

> I'm fine if it goes in too. Let's see what danpb thinks
> about it :)

  I think his intention is pretty clear from the bindings but I can wait.

> Christophe



-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124