On 10/17/06, Guenther Noack <[EMAIL PROTECTED]> wrote:
Hi!On Mon, Oct 16, 2006 at 12:39:21PM -0700, Yen-Ju Chen wrote: > I recently work on BookmarkKit a lot to be used in Mantella later. > An idea occurs to me that if Grr can also use BookmarkKit to store RSS > subscription, > then the web browser and RSS reader can work together better. > > [...] I totally agree to your mail. Since I am thinking for a long time about a rewrite of Grr now, seeing BookmarkKit appearing on the Etoile SVN was great news for me. I took a look at both Collection- and BookmarkKit yesterday, but I wasn't completely sure about how they work. I'm enlightened to hear that my idea of using BookmarkKit for Grr wasn't completely wrong. :-) However, I would like to keep the RSSArticle and RSSFeed classes for Grr, since they are the foundation of RSSKit. In BookmarkKit, I want to make Articles "items" and Feeds "groups" then. Is it possible to allow articles to be stored in multiple groups (like dynamic groups that store all bookmarks that contain a specific word)? (Doesn't need to be available now, but for the future I'd really like to have that.) So a item (=article) would need the following attributes: - article URL - title - read-flag (boolean) - creation date - podcast item URL (optional) - relevance score (iTunes-like 0-to-5-star-ranking, optional) - reference to RSSArticle object (optional (only if it's currently loaded to memory)) A group (=feed) would need the following attributes: - feed URL - title - feed icon (optional) - reference to feed object (optional (only if it's currently loaded to memory) Is that design acceptable? I haven't got a good overview over BookmarkKit yet, so please tell me if you think it's better to do it another way. > I haven't look at the internal of Grr for feeds. Basically, there are just two classes that you need to know. The feed class can be instantiated with a URL and has a fetch method that allows to fetch feeds. In Grr, the RSSFeed subclass RSSReaderFeed overwrites some methods to make fetching multithreaded and to add some extra features needed for the GUI. After fetching is done, you can request RSSArticle objects from the feed. Those contain a headline, content (which is unfortunately called description in the RSS1.0 standard), creation date and the like. In the future they may also contain author information and podcasts (which are just http links to multimedia files). RSSArticle is in Grr subclassed by the RSSReaderArticle class to have a read-flag. The RSSArticle class has also methods to store and restore itself to and from a file in the users home directory which location is determined by the article URL. This is done via property lists (a NSDictionary being the root node for an article). This is the way I'd like to store articles in the next Grr version, since it makes the application more responsive to load the whole articles just on request.
The CollectionKit is basically a generalized version of Addresses. It is a 2-tier system with item and group. It allows you to create items and group them in an arbitrary way. An item can appear in multiple group and group can be a subgroup of another group. And you can have arbitrary values and keys in items, even multiple values for a given key. BookmarkKit is based on CollectionKit with an assumption: each item can only exist under single group, and a group can only under single group. Therefore, the whole thing can be display under outline view easy. It also provide some basic properties commonly used as bookmark. Now, the issue is that a RSS reader is a 3-tier system. You have group, feed and articles. If you want to fit a 3-tier system into BookmarkKit or CollectionKit, both are 2-tier system, it will break a lot of assumptions and you have to override a lot of methods heavily. So my suggestion is to have BookmarkKit for group and feeds. It can use the default setting without any further modification. And the saved property list can be read by other applications. As for the articles, they are only used inside Grr. Therefore, it can be store in a separate CollectionKit, which gives you more flexibility. In this case, articles belonging to a feed can be group. So Grr will have two storage system, one is group/feeds (BookmarkKit), which can be shared, and the other one is feed/articles (CollectionKit), which is used internally. That's so far the idea I have.
> A second thing is the user interface of Grr. > Most RSS readers on surface are 3-pane style, > where subscriptions on the left in a outline view > and article on the right. > The other possibility is like GNUMail with subscriptons in a separated > window. > And it is what Grr has now. > People will expect to open multiple article windows in GNUMail-like design. > Otherwise, why put the subscription window separately. > Then Grr has to manage multiple article windows, > which I think is too much trouble. > Therefore, the 3-pane style would be easier from this point of view. > In any case, I suggest to make the subscription window a outline view > and move all buttons into toolbar as GNUMail: > http://www.collaboration-world.com/gnumail.data/screenshots/v1.2.0pre2/gnumail-gs.png > If Grr adapt BookmarkKit, it will be easy to do that. Okay. That's good to know. I was also planning to use a three-pane interface in the next version. :-)
That's good to know.
> Finally, Grr use thread to get articles asynchronously. > I personally prefer not to use thread if there is another way around. > NSFileHandle provide a way to get data through network asynchronously > without thread. > Netclasses (http://netclasses.aeruder.net/) provides similar function. > The drawback is that you need to do the hand-shaking manually > since NSFileHandele or netclasses does not know http protocol. > But I assume it won't be too complicated. I know that Grr had a lot of threading problems. :-> But threading is definitely needed, and the way it's implemented now is pretty clean and doesn't provoke crashes. The reason why the application still seems to have problems with that is that it doesn't properly update the GUI after fetching. But that's more a problem with my bad interpretation of the MVC pattern, which I hope to improve in the next version. :-]
Well, that's the problem of threading: hard to debug. And GNUstep-gui is not thread safe. If you fetch the article asynchronously, you won't have this problem. And it provides the same functions you need to fetch articles in the background without pause the user interface.
Thanks for the long mail. Apart from the threading issue, I agree with all of your points. :-) Before beginning to code, I would like to understand BookmarkKit in it's whole though. It would be nice if you pointed me to the code and documentation I should take a look at for understanding it.
You can look at the documentation of Address Book for Cocoa. It is the same idea. Yen-Ju
-Guenther
_______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
