12 January 2009

Rewrite/Redesign From Scratch

One of the commentors of the previous post pointed out the possibility of a clean start without rewriting the existing code base. The idea being that there might be people willing to start from scratch while unwilling to dig through an existing code base.

As of now, despite continuous attempts, I'm not successful with motivating developers to actively and long-time participate in Liferea development. Maybe a new restart with the same or another project name. With me or someone else leading everything. With the goal to provide an better alternative to Liferea.

So is there anyone out there, reading this, willing to start a new GTK or GNOME feed reader project in C or C++ in the next two months? Feel free to comment or contact me directly!

The alternative will be a redesign of the existing code.


Kenneth said...

Count me in for *either* a redesign or a rewrite. I need something to keep me from getting bored!

Ethan Osten said...

I'd be in for a rewrite, at least in C. Though I'd honestly prefer Vala most of the time, both because it's nicer to code in, and because I have a reasonably large codebase of an unreleased GTK C# feed reader, some of which could be ported for this if it was written in Vala.

see to learn said...

I think that Liferea is good as it is.

Foppe H said...

My experience in another project is that a plugin system is a great way to get (moderately advanced) developers interested in your application.
For me: I'd love to help but C is not my piece of cake.

Lars said...

Kenneth, Ethan: This sounds great. Thanks for your offers! I'm personally for a redesign because I fear a complete rewrite would take two or three months intensive work to get something working.

If you want let's met in #liferea on freenode.org. I'm usually there starting around 19:00 UTC. If you are interested in discussing a redesign I'd suggest to start a discussion on the mailing list

Ethan Osten said...

I can't be around until between 24:00 and 2:00 UTC, so I'm not sure how much I'll be able to talk via IRC.

Well, I agree that the long turn-around time is a definite downside to a rewrite. But I'm not sure if it's that big of one, in the long run.

First of all, I don't think this would be something that needs immediate results to be practical. As long as the core people working on it are dedicated (which I'm assuming we would be), we could keep working on it until it was ready. Meanwhile, everyone else could continue to use Liferea 1.x, which could still see small updates and fixes and whatnot until the rewrite was ready to replace it.

Besides, rewriting does bring some substantial benefits. For one, it allows for the design to be more-or-less intended from the start, and for it to be written that way, which would improve the implementation as opposed to a retroactive one. It also has the advantage that it's easier for new developers to get into a rewrite than a redesign; a redesign requires extensive knowledge of the codebase, much more than simply contributing does; just bringing people up to speed on the code would be a lot of work, especially since parts of the Liferea codebase were - at least back when I was looking at it - fairly opaque.

But I'd work on either.

Anonymous said...

Why C/C++? Mayby Vala or D+gtkD ? I was thinking about feed reader in D, but don't have enaugh time currently.

Lars said...

Ethan: Yes, the timezones are quite a problem. Let's get in contact per mail if nothing else works.

BTW right now most of the people interested in participating (I count at least 4) vote for a rewrite of the existing code base.

If you worry about troubles with the existing code: I think we can circumvent it by me identifying the relevant place, removing the old code and providing hints at the problematic places.

Anonymous: I understand the enthusiams in using newer feature-rich programming languages. But IMO it is a realistic expectation when considering the additional learning efforts quite high. Also new language runtime environments tend to be unstable or not even available in all distros/on exotic platforms

umonkey said...

I don't think that you need to "rewrite from scratch" to improve the software. You could start by modularizing and isolating the functions, and have great results step by step.

But I really wanted to comment on the plugins. I think it's very important to use a popular script based system, such as Lua or Python or whatever, just don't use precompiled binaries. This would make it possible to have a self-maintained up-to-date distro-independent repository, instead of waiting for someone to approve, review and package each plugin. You know.

Thomas said...

You might find The Cathedral and the Bazaar by Eric S. Raymond interesting.

It might not help you at all, but I hope it'll help in making a decision.

ujjwollamichhane said...

I think new liferea should use webkit as rendering rather than geck...

Anonymous said...

ujjwollamichhane: Liferea is already using Webkit

John M Lang said...

Some sort of online synchronization between Liferea instances on different computers would be nice.

I'm currently using Dropbox for this, but it is less than optimal.

In any case, thanks for making such great usable software. Yeah, the performance isn't consistently good, but Liferea is still the best RSS reader out there.

Anonymous said...

Lars you can be right. I am using D since 2006 without problems (1.x branch). But there is some problems on non Linux, non Intel platforms.

Hope new Liferea will be the best RSS feed reader :)

I currently have some stability problems with it (Liferea eats lots of CPU not doing antyhing usefull :D And i must kill -9 to exit all the times), but I like it anyway :)

Anonymous said...

I'm not a developer, just a user, and this is probably the wrong place to put this, so apologies in advance. Liferea is a great feedreader generally, slightly slow on an old computer.

In using search folders, I've found that mark as read (in just that search folder) works for the latest bolded entries, but scrolling down through some of the folders will find other bold entries that don't seem to get marked or returned to non-bolded entries, however, the number next to the search folder that shows a new entry count does seem to work properly. This doesn't seem an issue in subscription folders, only search folders.

I've also needed to use the clipboard viewer with Liferea. When I'm viewing a search folder item or news story, I often want to know what subscription the story comes from, the user interface doesn't seem to show that information.