rssview-developers

[Rssview-developers] RSS

[Joerg K. W. <we...@in...>]

Hi,

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.

Please contact the other developers and project admins to manage these 
things. Please keep me up-to-date, if you plan a cooperation. As already 
mentioned i've interests in PRISM and CML2 standard support including 
plugin-mechanism for image generation and export functionality for 
chemical file formats for CML2.

http://sourceforge.net/projects/hotsheet
http://informa.sourceforge.net/
http://sourceforge.net/projects/jsurfer
http://www.jsurfer.org/risotto_install.php

Kind regards, Joerg
-- 
Dipl. Chem. Joerg K. Wegner
Center of Bioinformatics Tuebingen (ZBIT)
Department of Computer Architecture
Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany
Phone: (+49/0) 7071 29 78970
Fax: (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW:    http://www-ra.informatik.uni-tuebingen.de
--
Never mistake motion for action.
                                     (E. Hemingway)

Never mistake action for meaningful action.
                                (Hugo Kubinyi,2004)

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

Re: [Rssview-developers] RSS

[schmidtm <mat...@mo...>]

Hi *,

I agree with Martin. I think the CVS-version is fairly different from 
the last stable release, so we should do a new release first. And to 
make this release,  we really need to get the bugs out. I filed four 
bugs, and I fixed one today. I will do cvs-commits this week. Most of 
the Bugs are of the type: This View gets not updated, when this happens 
and so on. I spend quite some time to track them down.

So don't get me wrong, I totally open to make improvements, even major 
overhauls, but we need to get a stable release out which reflects all 
the changes since 1.2.0 dating from March 2003.

cheers,

Matthias


Am 06.04.2004 um 18:27 schrieb Martin:

> 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
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Rssview-developers mailing list
> Rss...@li...
> https://lists.sourceforge.net/lists/listinfo/rssview-developers
>

Re: [Rssview-developers] RSS

[Joerg K. W. <we...@in...>]

Hi all,

just ensure that you are not inventing the wheel twice, which is not 
necessary for open source projects.
Please have a look at other code !

Kind regards, Joerg


>>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
> 
> 
> 


-- 
Dipl. Chem. Joerg K. Wegner
Center of Bioinformatics Tuebingen (ZBIT)
Department of Computer Architecture
Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany
Phone: (+49/0) 7071 29 78970
Fax: (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW:    http://www-ra.informatik.uni-tuebingen.de
--
Never mistake motion for action.
                                     (E. Hemingway)

Never mistake action for meaningful action.
                                (Hugo Kubinyi,2004)

Re: [Rssview-developers] RSS

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

Am Tue, den 06.04.2004 schrieb Joerg K. Wegner um 22:48:

> just ensure that you are not inventing the wheel twice, which is not 
> necessary for open source projects.
> Please have a look at other code !

We are going to look for an external parser for sure.
It's too much work to make a solid one from scratch.

Martin