Paul Louden <paulthenerd_at_gmail.com> writes:
> I responded to it with "sounds like" because I literally mean that's
> what it appears like to me. I thought I had responded to your actual
> objections as well, further down, but since you linked me to a
> flyspray task rather than spelling them out I was left to my own
> ability to pick them out of a post that wasn't just about your
> objections to using bookmarking.
This may have been a misunderstanding. I actually meant to spell out my
reasons for not basing autoresume on bookmarks in my e-mail messages
(but probably didn't do a good job).
I was referring to that Flyspray comment not as the main source of these
reasons, but only in a personal parenthetic/footnote remark meant to
illustrate the bookmarking system's configuration and implementation
complexity by way of the hassles I've had with it. The points I wanted
to make were:
* Bookmarks (as they exist today) are much harder to use and to
configure correctly, and have much higher implementation complexity,
than the proposed autoresume feature.
* Basing autoresume on bookmarks is going to make bookmarks even harder
to use, configure, and get right.
* Yet, the inquisition is all over me for a feature that is
comparatively trivial to use and simple to configure.
> I'd be happy to have you state your objections clearly so I could
> understand better.
My reasons (not objections) for basing autoresume on the DB rather than
on bookmarks were:
* Code complexity: No need to do any explicit file I/O, or to parse /
write text-based bookmarks. The DB already handles I/O and
* Simplicity due to similarity to existing code: Reading and writing
resume information is done in the same functions and in the same way
as reading/writing DB-based runtime statistics (play count, play time,
* Performance: The DB typically already has the required resume data
cached in the critical path during automatic track changes (the DB is
consulted when the codec initiates a track change or earlier), and the
metadata write is already nicely deferred to not interfere with track
* Features: The resume offset can be queried to generate interesting
database views. For example, in my tagnavi_custom.config file I have
defined a view that lists all unfinished podcasts.
* No need to invent a new file format (or extend an existing one) to
store per-file resume points.
* I prefer storing per-file metadata in the DB rather than in files
because having a per-file bookmark would clutter the filesystem.
> As well, the advantage of bookmarks is that auto resume would always
> be available, whether or not a user was using the database, rather
> than forcing them to. This seems fairly significant to me, since there
> may not always be space for the database. It can grow quite large if
> there's a large number of files.
Yes, that's a shortcoming of any DB-based feature (DB browser, runtime
statistics, track rating), but no one _forces_ anyone to use the DB. No
feature is for everyone.
Various people have suggested to mitigate this issue by allowing tracks
to be added to the DB as they are played. That would allow all users to
take advantage of autoresume without requiring the DB to be initialized
with all tracks.
Received on 2011-01-06