Rockbox mail archiveSubject: Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)
Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)
From: sideral <asieoniezi_at_gmx.net>
Date: Tue, 04 Jan 2011 14:54:19 +0100
Paul Louden <paulthenerd_at_gmail.com> writes:
> Basically it sounds like your objection to improving bookmarking is
> "it's buggy"
I am sorry to see that you respond to what my "objection" "sounds like",
rather than responding to the individual arguments I've made. I
understand the need to summarize a long argument in a catchy phrase, but
your statement is wrong on so many levels that it verges on insinuation.
First, I never objected to improving the bookmarking system. In fact,
I'm all for improving the bookmarking system.
Second, I chose to base autoresume on the DB rather than on bookmarks
not because bookmarking is buggy, but for a reasons that will become
obvious to anyone who looked at my code: The DB is the storage medium
that has all the parsing and I/O infrastructure readily present and also
is the easiest to access from the code in question, leading to an
implementation in a few lines of code, sitting next to the code that
handles DB-based runtime statistics.
Third, you assume that I would shy away from using bookmarking purely
because it is buggy. I think I have demonstrated that this is not my
motivation: The DB is buggy as well, and I have found and fixed three DB
bugs in the course of my work (FS#11721, FS#11722, and FS#11723).
> but those bugs need to be fixed either way, and if they would address
> most of your expressed concerns, that's a net win.
The concerns you quoted only served to illustrate that bookmarking is
quite complex, leading to quite an annoying number of bugs. I'm all for
fixing these bugs. But I never said fixing these bugs would go most of
the way towards implementing an autoresume feature.
You chose to not quote, and not respond to, my actual concerns for not
using the bookmarking system.
> There's no reason why the UI for resuming bookmarks couldn't function
> similarly to auto resume *plus* having the expanded capability of
> allowing people to have multiple bookmarks.
Given that autoresume is intended to be used independently from the
bookmarking UI, there's also little reason _for_ basing the feature on
bookmarks as a storage mechanism. With both features coexisting, the
net result is the same (autoresume + capability to have multiple
bookmarks), modulo that the DB is needed for autoresume.
I found the arguments against using the bookmarking system (complexity
of implementation and configuration) outweighing the ones in favor (can
be used w/o DB). YMMV.
> The objection I have to your UI is "it's more complex than necessary
> to expose the functionality."
And I find your proposed UI (explicit "queue for resume" function) more
complicated to use, whereas the nice thing about my autoresume proposal
is that it has _no_ UI except for a one-time configuration. It just
quietly works its magic.
We disagree, but there's no reason not to provide both UIs. This allows
the user to make the tradeoff between complexity of use vs complexity of
configuration, rather than you or me.
> If the bookmark UI can be streamlined to expose the same functionality
> while being less complex, I'm all for it, but there's a difference
> between objecting because "it's complex" and "it's more complex than
I'd be happy to review anyone's implementation of autoresume based on
bookmarks. Then we can compare the two implementations to see which is
Received on 2011-01-04