On 2/17/07, Guenther Noack <[EMAIL PROTECTED]> wrote:
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.
Regarding the happiness issue,
I mentioned in one of our private emails that when new Grr(r) is in svn,
I will move Mollusk into the branches.
I haven't see Grr(r) in svn, therefore, I haven't move it out yet.
That is also the main reason for the renaming
so that new Grr(r) can be imported without any conflict of naming.
[snip]
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.
CollectionKit and BookmarkKit is directly extracted
from Addresses for GNUstep,
which is a clone of AddressBook Kit from Cocoa.
All the concept of AddressBook Kit will apply
to CollectionKit and BookmarkKit.
One of the features is that you can add new keys to it
without affecting any other application.
Therefore, it is easier to shared by many applications.
- 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.)
It can be seen as a feature or not.
An object provides a solid interface for its internal structure.
What if the next version provide slightly different structures ?
Then an upgrading system has to be provided.
and there is usually no downgrading system.
Therefore, all applications has to update to read the new data structures.
What if another application want to add some stuff on the data, say tags ?
The change will propagate to all other applications.
AddressBook Kit solves this issues by providing a solid interface
for flexible data structure.
It is more like a database API
where you don't see the internal data structures.
But again, it allows you to add new keys (fields in database) on a fly.
- Isn't it quite slow? It stores things to a Plist.
iTunes stores its database in plist.
I have thousands of songs and I haven't feel any drag.
In order to use it for iTunes-like application,
all we need is put the path of each song in the plist
then you can turn Mollusk into iTunes-like manager.
- 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?
It is not done yet. :P
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.
If it does not fit, there is no need to use it.
It just provides another option.
By the way, CollectionKit handles data more like Key-Value-Coding (KVC)
Say there is an object with two variables: number1 and string2.
Instead of writing interfaces like
- (void) setNumber1: (NSNumber *) num;
- (NSNumber *) number1;
- (void) setString2: (NSString *) c;
- (NSString *) string2;
KVC provides another way to do so by using:
[object setValue: num forKey: "number1"];
[object valueForKey: "string2"];
In this case, developers don't need to write getter/setter anymore.
It is very similiar to CollectionKit's approach
except KVC acts on object while CollectionKit acts on data.
Again, it is just another option.
Yen-Ju
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
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
