This did cross my mind yesterday also. I'd definitely try such a service for convenience, but it'd be a bit of a shame to create a single point of failure in something that's otherwise fairly distributed. Syncing with another linux box doesn't really achieve what i'd like as you suspected, since my whole goal is that the tablet does everything. I am playing with the desktop version too though to get a feel for it's speed. Even that sat on the 850 item feed for a few minutes, so I think a lot of this is harsh reality on the imperfections of RSS rather than differences in processing speeds, of course not discounting that entirely.
I definitely like the look and feel of the application. Ironically when I first tried to use it in verbose mode I missed off the maemo flag and launched it with the normal interface and thought it fitted quite well. If there's one thing I dislike about maemo it's the single menu interface which tends to translate to 3 clicks to do anything, though I suppose some of the changes do lend themselves to extra space for the actual content etc.
- As above, I think i'd like the application a lot with a web aided service, although I wish there was another way. I wonder if maybe a compromise might be a small RPC style service to take a feed, order and/or shorten it, then return it to the application which could process it more quickly, now being able to make some assumptions. Then of course, the fall back to the service being unavailable could be the original method, so it would continue to work. That might not be as lightning fast as having a remote server do all the work, but it might create less of a dependency. The alternative seems to be something updating feeds on server, on a schedule, similar to Google Reader. I'd imagine that would be fastest, but be a huge dependency and be more complicated to code.
- The database stuff (displaying episode lists) has a little lag too although I suspect you've got that as tight as you're going to get it in an interpreted language. That's perfectly bearable and doesn't seem much slower on the larger stored feeds. No slower than Video Center's similar functionality.
- The parsing speed on a morning where only 3 feeds had changed was quite bearable. It's when a lot of people push out content at the same time the time gets harder to take. 5-15 minutes seems to be the range for my now 19 feeds, although this gets done in the hazy first 30 minutes after having woken up so I may be distorting time in my mind
- This morning I let it launch into 5 downloads at once. The interface didn't move again until three of the files had fully downloaded, then I saw the final two progress together. I will try configuring it to do 2 at a time tomorrow as I've only just noticed it's an option. It feels more like the downloads are maxing the processor out rather than the connection. Does it/can it yield at all during downloads?
- I am having trouble adding a feed. It failed to add from the OPML (the only one as far as I can see) and now it won't let me add it from the interface. It seems fine in the desktop version. The only thing I can think of is that the domain has a hyphen - it's http://www.manager-tools.com/feed. No other URLs in my list contain a hyphen.
- A startup page might be preferable to the top feed in the list being fully displayed. From what I can see this would give the user access to the interface a little more quickly. When in verbose it looked like most of the startup time is spent loading that feed. After a few days I realise i'm barely noticing this delay. Video Center by comparison takes ages to start up, although it didn't in older versions. - Another thing I like about Video Center is the little list of recent downloads. Again, from a speed point of view, if there was a way to list the four files I'd just downloaded in one view and hit play, it would feel faster than having to display the feed to get to the downloaded episode. Do they need to disappear from the Downloads window as soon as they're downloaded?