* Lars Lindner <lars.lindner@...> [2006-09-23 13:45]:
> Am Samstag, den 23.09.2006, 02:48 +0200 schrieb A. Pagaltzis:
> > I want to poke my head in there a bit more when I get the
> > time. The problem is how to make myself care enough.
> If you want I could add some really annoying bugs :-)
> As for the reliability, one can never be 100% sure. And
> switching to Sqlite will cause another migration.
Well yeah, but that won’t munge the entry content.
Entries can disappear wholesale maybe, but there won’t be cases
like what I had with the first version of the migration code,
where the first couple of sentences of many entries remained, but
the rest of their content was gone. Depending on the feed to
which it happened and the age of the entries, if that bug didn’t
get triggered so often, I might never have noticed. This is the
kind of thing I am afraid of.
In contrast, missing feeds or entries entirely is easy to check
for. I just need to run an queries on the XML files and the
database to check the numbers; that is trivial.
> In this case the conversion is the price for getting XHTML
I know. I am not complaining about it. I am just saying that
there is a content conversion process, and these are always
All this is making me more certain of an aggregator design
decision I have made for my vapourware idea: always keep a
pristine copy of the original XML fragment that makes up a feed
entry. Stuff you pull out of that can be put into the data store
along with the original markup, but that’s purely a caching
mechnism to avoid reparsing the entry time it is viewed. (But
considering that an entry is typically viewed just once, and
rarely more often than thrice, it’s questionable whether that is
Then the content is never converted (every conversion is lossy to
some extent), so none of the original information ever gets lost.
Also, if a new version of the aggregator gains support for some
extension it didn’t understand before (f.ex. I think the Atom
Feed Thread thing is going to get big in the future), all the
archived content also benefits from it.
I’m not sure it is feasible for Liferea to adopt such a policy at
this stage, though.
Aristotle Pagaltzis // <http://plasmasturm.org/>