On 2015/05/19 16:47, Yclept Nemo <orbisvi...@gmail.com> wrote:
> Well it is both mpd-specific in the labelling
> * schema name: org.mpd.smbclient.password
> * collection label: MusicPD
> And smbclient specific in
> * password label: Smbclient Password: {server}
> * schema attributes
>
> There is a tool secret-tool, but it doesn't allow for:
> * collection creation
> * storing a secret in a specific collection
>
> This tool does both, and automates the process specifically for mpd keyring
> users.
I have no idea what any of this means. But for what it does (look up
a password), this (and the rest of your email) sounds excessively
complex.
I mean, whoa! Glib main loop, querying asynchronously via DBus. To
look up a password!
> As used this diagnostic requires GCC >= 4.6, but this is a global mpd
> requirement so I won't version. From Compiler.h:
> ....error Sorry, your gcc version is too old. You need at least version 4.6.
> SecretSchema is (an opaque?) data structure with reserved fields
> SecretSchema::reserved1-reserved12. If this fields aren't used GCC
> generates some pretty ugly warnings.
If it's opaque, can you really initialize it that way?
> IMO if you malloc data and cast to const you should be able to free it; can
> free by recasting as non-const.
Only if you use const_cast, which is a kludge. You can do everything,
but not everything is good style.
> Well, some problems in making libsecret async:
> 1] Integrate libsecret's mainloop (glib) into mpd's (chosen during
> configure?) or vice versa.
Never again GLib main loop. I'm happy it's gone.
> 2] Entry point for the async return callback can't be
> mpd_smbc_get_auth_data (1st arg to smbc_init) because that's already a
> callback and smbclient will initialize as soon as it returns.
That's the problem I was talking about: libsmbclient is synchronous.
And that callback is, of course, also synchronous.
> So it seems the async point would have to at SmbclientInit() or higher, and
> any function that calls this (storage, input, neighbor) would have to be
> split with a return async callback. Thing then get complicated with locking
> the use of any smbclient-mpd related datastructures until the callback is
> called. High complexity for minimal returns (listening to radio).
Actually, that's a fairly standard problem in asynchronous
programming. That's the easy part.
MPD's "curl" input plugin is asynchronous, too (for listening to
radio!), and it works very well.
And MPD's "libnfs" input plugin is asynchronous, too - but developing
it was a pain, because there are a few API deficiencies in libnfs,
which require big kludges in MPD (no cancellation, which is an
important thing in asynchronous programming).
Max
_______________________________________________
mpd-devel mailing list
mpd-devel@musicpd.org
http://mailman.blarg.de/listinfo/mpd-devel
