Hi!
That whole Mollusk/Grrr thing is indeed a bit fuzzy. To clear things up,
here's the story from my perspective. First, the non-technical part that
explains the different versions of Grr(r) and Mollusk. It's a bit lengthy,
but unless you're interested in it, you can skip the paragraphs about the
exact history of the RSS Readers and their exact differences.
EVOLVEMENT OF THE DIFFERENT VERSIONS
In the end of 2006, Yen-Ju asked me if he could integrate BookmarkKit
into Grr. I agreed, but also warned him that I already started making
first tests for a next Grr version which was going to be a complete
rewrite to overcome architectural issues. (This rewrite is what became
later known as Grrr. Note the extra 'r' which indicates 'development
version'.)
So Yen-Ju started integrating BookmarkKit into Grr. Soon, it started
to change much faster than I could follow the development. It became
very different to the original application. Ultimately, Yen-Ju proposed
to rename it to Mollusk to indicate the differences between Grr and its
BookmarkKit version.
Timeline
end 2006 ---->---->---->---->---->---->---->---->----> feb 2007
[Grr 0.6] ----------------------------> [ Mollusk ]
the big refactoring
[*] ------------------------------------------> [Grrr 0.8]
complete rewrite
I am also not particularly happy with the situation that there are now
two RSS Readers on the Etoile repository, as this all looks like
duplicated effort again. But if I remember correctly, Yen-Ju also
considers Mollusk more like a developer example and testing platform for
BookmarkKit than a competing application.
TECHNICAL DIFFERENCES
This story makes possibly not so much sense without explaining the
technical aspects of these applications. First, let me describe the
original Grr version:
The original Grr version was one of my first tries with Gorm. So there
are no real controller classes, no Cocoa-style MVC. A well-meant
external patch that split the single Gorm file up into multiple Gorm
files later proved to integrate badly with the broken architecture,
which made it even worse. Grr had a feed and an article class
(subclassed from RSSKit) which were very central to the application.
Instances of these classes were passed around by the application logic
everywhere.
Mollusk, from my point of view, can be characterized by two major changes:
1) Complete refactoring of pretty much everything, probably to
make it more MVC-like. (I didn't understand it completely.)
2) No more references to any article instance. These have all been
replaced by BookmarkKit stuff.
Grrr is a rewrite of Grr that I did to overcome the architectural
weaknesses I introduced in Grr. The main differences to Grr are:
- Clean MVC, the Gorm files make sense now to me :)
- Component based architecture, much like JavaBeans, but a bit more
specific to the application's needs.
- As much as possible is moved into bundles.
- Instead of the RSSFeed and RSSArticle classes, I reference the
<Article> and <Feed> protocols.
Note that the only part of the application which gives out references to
<Article> and <Feed> implementing objects is the database bundle, which
is of course exchangable. This allows to build a database plugin based
on BookmarkKit.
BOOKMARK KIT
I still have a couple of things I don't understand about BookmarkKit.
When CK and BK were written, I thought it would enable me to write
iTunes-like collection management applications easily, but that was
obviously a misconception. I'm now struggeling to figure out what's
so good about it that I should use it in Grrr.
- Data is strictly non-object-oriented. (A CKItem is not much more than
a struct, it has no methods except getters and setters. Don't say I
can subclass it - I possibly want to subclass something else, like for
example the RSSKit article class.)
- Isn't it quite slow? It stores things to a Plist.
- IIRC it was supposed to be Newton-soup-like in a way that multiple
applications can access the collection at once. Grepping the CK
source code for "sync", "lock" and other keywords, I get no
results. I have the impression that it doesn't work yet?
Finally, there's another big problem that I see with it: When writing a
complicated class for an application, the data storage methods of that
class are a very small part of that class and relatively easy to write.
In addition to that, it doesn't integrate too well in existing
applications. You don't sacrifice your application's architecture for
functionality that you can also have by writing a store and a load
method.
Bot on the other hand, I'm not really a BookmarkKit expert and chances
are pretty good that I'm just missing some important point about it. I'm
open for corrections. :-)
-Guenther
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
