Max Kellermann <[EMAIL PROTECTED]> wrote: > Hi, > > I have rebased my git branch on the official git repository. I have > merged everything up to f9f70860. Although I still believe it is a > very bad idea, I have also merged the patches which create the global > variables "dc", "pc", "ob", but I will revert them as soon as there is > a real need for more flexible code.
In other words, you'll never need to revert them :) > What follows after f9f70860 is the huge monolithic patch 44d9f62f, > which is very difficult to merge, since much of it had already been > addressed by my patches. I havn't bothered to merge 44d9f62f yet, but > I believe it does not provide advantages over my (small and > self-documenting) patch series. The advantage is that the current maintainer (me) understands the entirety of it. Of course this is all subjective: The state transitions are more clearly defined, as is crossfade (without wasting half the buffer space when not crossfading as you proposed with two output buffers). Of course, the unnecessary state management logic in between queue/playlist/player locking and interaction is now gone. Unnecessary initialization/flush/clear routines in inputPlugins are handled implicitly without any action on the part of the inputPlugins. > This patch set contains all of the old patches which have not been > merged to Eric's branch yet, plus some more cleanups. I have tried to > sort the code into several sources: there is now Thanks for prefixing the subject line of your commits, it'll be easier for me to sort them out and cherry pick changes as needed. > decoder_thread.c (the core of the decoder thread) > decoder_control.c (controlling the decoder thread) Given that I've gone ahead and done the core-rewrite swap, these are unlikely to be merged. The changes just lacked direction as to where they were going and core-rewrite was a place where I really needed things swapped out in one fell swoop to see things clearly. Sorry if it threw you off. > decoder_api.c (public API for decoder plugins) I definitely like the idea of exposing a single header to everything under inputPlugins/* and limiting access to MPD internals. > For the player thread, it's similar. > > Note that I have also merged Eric's HTTP client patches, although they > contain a critical regression. I will address this bug later. HTTP > streaming does work, but in some error conditions, MPD hangs forever. > I'm not sure if it's worth it to hack the HTTP client code at all, we > would be better off with linking against libcurl or any other HTTP > library. HTTP is more complex than it should be, and our code > contains huge amounts of bugs, iow: it only works for the special case > it has been tested with.. HTTP is simple. Sure there are bugs (not "huge amounts" as you claim) with our code, and I'd rather fix them ourselves than deal with linkage/library versioning issues. Curl (as packaged by most distros) is far too bloated for my tastes. Ideally, it would be great if operating systems offered paths like Plan9 (e.g "/net/http/example.com/80/mpd.ogg") to access. But we're probably still a decade from that becoming common place enough that we won't have to support HTTP at all explicitly. > As usual, you can pull my branch from repo.or.cz: > > git://repo.or.cz/mpd-mk.git > http://repo.or.cz/w/mpd-mk.git > > Eric, please tell me the local path for git+ssh access on > git.musicpd.org, so I can push it over there, too. >From http://article.gmane.org/gmane.comp.audio.musicpd.release/1: [EMAIL PROTECTED]:git.musicpd.org/$USERNAME/mpd.git Since we're on git now, I strongly prefer you not send massive patchbombs (especially if they're repeats) anymore. URLs, SHA1s and shortlog output is fine. For a few one-off individual patches, the mailing list is fine. Thanks, -- Eric Wong ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
