Re: [Rssview-developers] RSS

[Martin <cin...@gm...>]

Am Tue, den 06.04.2004 schrieb Joerg K. Wegner um 13:14:

> i would recommend to use
> - the informa parser as kernel (seems to be the most advanced RSS parser 
> out there, including name spaces)
> - rssView (good layout),HotSheet (simple, but informa as kernel),Risotto 
>   (not looked at) combination as visualization.

We don't have any suggestions yet, what we will take for an RSS-Parser
and how it will be implemented. We should keep the interfaces as general
as possible (if it is possible at all). Perhaps we can establish a
standard here. Just to be a bit arrogant :)

---

I recommend first that we FIX the problems with RssView first, before
we work on extensions. Many people want to see a release, I noticed.
But I will not allow to release RssView in the current state. I know
that bug fixing and improving performance is boring, because it does
not change the project visibly, but it is essential for usability.

I want to suggest something.

Every time you see something that a user does not expect to happen,
please submit a bug report or fix it directly, if it's trivial.
I can see many things which the user does not expect. The root node
does not look good and it does not show ALL articles when I click
on it. This is a bug for me. I have already looked how to fix it
but instead I found more and more problems. Same refers to folders.
When I click on a folder, I want to see all newsfeeds in the
folder and all subfolders. This is intuitive and people like it
that way.

Please look at the details in the GUI-part. I liked the idea to
have icons in menus, but there are still missing icons. Some dialogs
don't have default handlers. This is all annoying for the user.

There are also things which the DEVELOPERS don't expect in our
project. I made some notes in the SQL-part. The design
is not clean enough for my taste and even dangerous in various
places (I think, I made a comment about "SELECT * FROM table" somewhere)
and also how to use SELECT to get more precise information from our
database. We are also losing performance there. Some people will
also ask about a feature how to delete old articles automatically
from the database. Other people will want to empty a channel.

When you have questions, I am here and will try to answer.

---

Now back to architecture:

We have many options how to structure the project. I would like to hear
more opinions how to modify the structure of the project to enable it
to read more than just regular newsfeeds.

I already mentioned what I would like to see. I like a plugin-like
interface to show extra-stuff. I liked the suggestion to make the
plugin-interface "sense" automatically if it can view certain types
of data by using reflection.

The application should handle the "special objects" like this:

- autosense all available plugins for a type of object
- choose one, which the user has decided to use
- optional: test if data is compliant [if not choose next plugin]
- ask the configuration of the plugin about how to handle
  the object
  - view inline
  - separate window
  - pass control to other application
- do the job (with parameters above)

Looking at this structure, we could also make the RSS-Parser
a plugin. It would be nice to have a fallback (you never know).

Sincerely, I don't have an idea how flexible the design above
is, because I haven't look at the RSS-standard close enough.
Perhaps someone of the others can comment on it.

We should talk a bit about the architecture and make some notes
about the ideas, in READMEs and in RFEs. This way we know where
we are going.

Martin