-----BEGIN PGP SIGNED MESSAGE-----
On Wednesday 08 December 2004 14:48, Frerich Raabe wrote:
> On the other hand, the 'librss' which aKregator forked handles much more
> than RSS - it works with Atom-style feeds as well. Since this is entirely
> beyond the scope of librss (it's not called 'libsyndication' for a reason),
> the way Atom support was added in a way which is very error prone and as it
> is right now I am not terribly fond of the idea of adding that to
> kdenetwork's librss (which is what knewsticker and dcoprss use).
Well, we don't want to add the current code as it is into kdenetwork librss,
our concern is to get our additional features supported in some way without
duplicating librss code.
If haven't missed something, there are two major features added by Sashmit
(correct me if I am wrong as I hardly touched librss so far): Atom support
and feed detection (i.e. searching for linked feeds in HTML source).
The feed detection code should be removed from Loader in my opinion. The
Loader could emit a signal when parsing goes wrong and then the detection
could be done in the akregator code. I already isolated the actual feed
detection, getting it out of Loader is still TODO.
With Atom support, there are three alternatives I have in mind:
a) Leave it as it is for now and merge backend and apps later (i.e. after KDE
Pro: kdenetwork/librss stays stable as it is and our bugs don't bother
Con: We got to maintain the independent versions during the KDE 3.4 life cycle
b) Merge features, keeping the current librss structure, e.g. add atom support
to Document::Document(QDomElement) like it's done now, but rewrite it so it's
Pro: No duplication of code
Con: The constructor gets complex and ugly and there is a possibility that
bugs in the new code affect the already well tested RSS parsing. Also, librss
c) Restructure librss: Create an abstract parser interface and use subclassing
for the various syndication formats.
Pro: parsing code gets cleaner, Atom parsing is separated from the RSS/RDF
code and could even stay out of librss without duplication.
Con: Needs rework in librss which could introduce new bugs
> Yes, this is a worthwhile goal IMHO. I've been brainstorming about merging
> the backend facilities (read: fetching stuff using librss, maintaining
> a list of newsfeeds) into a 'libakregator' library, and then merging
> knewsticker into aKregator, so that it still seems to be an independant
> application, but really only is an aKregator in applet mode. The
> ticker-specific settings could be added as an additional page to
> akregator's configuration dialog.
I agree, that could be a long-term goal for KDE 4.0.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
-----END PGP SIGNATURE-----