[mpris] [ANN] libmpris

[Jorge Villaseñor]

2010/5/21 Mirsal Ennaime <mirsal.ennaime at gmail.com>:
> 2010/5/21 Mirsal Ennaime <mirsal.ennaime at gmail.com>:
>>> Also, I was thinking about moving it to use eggdbus but maybe it will
>>> be better to wait until 2.0 to move code.
>>
>> It would add significant dependencies that are very large compared to
>> the size of the lib and it would mean a major rewrite. However, it's
>> not necessarily a bad thing, especially if the result is several
>> orders of magnitude more maintainable.
>
> I've been thinking about this, EggDBus makes a lot of sense for
> GObject-based code. However, I'd rather either make it a separate lib
> or keep the low-level dbus code around along with a compile-time
> switch, because of the original purpose of libmpris.
> (it was meant to be a very lightweight layer with as few external
> dependencies as possible which could provide a relatively easy access
> to the mpris interface without the need for large dependencies like
> GObject).
> If a project uses high level libraries which include dbus bindings,
> then it is very likely that those bindings enable an easy-enough
> access to the bus so that the need for an external dependency is not
> justified.
>
> If nobody uses the low level code, it might just disappear anyway.
>
> My two cents ;)

I agree and looks like a good idea to me. Do you think it worth to
port it now or wait until version 2 is finished and just write the lib
for the new revision? Maybe adding another configure flag and maintain
code for MPRISv1 and MPRISv2 in the same repo, what do you think?

Regarding of the mainternership of the project, I don't have issues
with maintaing it. I can add your key to github repo so you can push
there or if you have a better place to host it, we can move over
there. It would be really nice to have an active bugtracker and more
distro packagement (I'm maintaining it in the Archlinux User
Reposotry).

-- 
Masca