Help proposal for Akregator

[Sandro Knauß]

Hey,

> I plan to do that yes. I don't think it's going to be worse than what we
> currently have (the Metakit files already store the entire articles).
> For huge archives (>2GB maybe ?) SQLite may hit some limits and something
> stronger like PostgreSQL could be helpful.
> But I don't see how it could not be far better than our current Metakit. I
> also think that the current system has huge performance issues that we will
> solve using SQL queries to order articles instead of fetching every article,
> filtering and sorting using QSortFilterProxyModel. This will take a few
> months, but after I write a data migration solution I hope to be quickly
> able to demonstrate the final benefits using my archives.

Great, that you are started the task of maintaining Akregator.

I still think that we should not forget, that Akonadi is exactly created for 
handling the storage and accessing big data sources like it is done for mails.
That's why it makes sense if you would share your ideas of how your new 
archive system should work. Maybe we find a solution, where also a later 
Akonadi replacement would benefit from. I just thinking, that a redesign of 
Aktrgator could push the code in the right direction. For switching backends 
easily, it makes sense to have a clear layer between interaction of SQL  
database and application and do not add direct SQL commands everywhere in the 
code...

Btw. a QSortFilterProxyModel is a very powerful thing and you won't miss this 
and it can be really fast is used correctly. Get in contact with Volker Krause 
and Milian Wolff, both are know the tools to find bottlenecks on Qt stack very 
good. Often those have found bottleneck nobody had expected so far and with 
only some small changes the applications got a lot of faster.

sandro