On 10/3/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
Le 2 oct. 06 à 20:46, Yen-Ju Chen a écrit :
> On 10/2/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
>
> So there is the concept I have:
> Applications read and write through BookmarkKit,
> which abstract the backend database.
> Each application can has its own domain, just like NSUserDefaults.
> And each domain can just be a database.
> An indexer can just crawl through all databases for searching
> later on.
> BookmarkKit behaves as a manager for all the databases.
>
> It is not hard to store the records in database one by one.
> But we also need to store the organization of records as in my
> second email.
> In this way, BookmarkKit need another file, probably an NSArray,
> to keep track which records belongs to which group.
> Therefore, a complete domain in BookmarkKit contains a database for
> all records,
> and a property list for the group.
> They can be put together in a bundle.
>
> Does it look reasonble ?
I'm not really sure to understand, neither I make myself very clear.
My vision was the following one…
Either several databases (each one shared between all applications or
used privately by a single one) dedicated to:
- bookmarks
- contacts
- mails
- etc.
Bookmarks would be available to any applications through BookmarKit,
contacts through AddressesKit. But mails would be used privately by a
mail application.
Or instead of the three previous databases, just a single one where
the previous stuff (shared or private) is stored together :
bookmarks, contacts, mails etc. This is what I understood from your
initial plan when I read you first mail. I could be wrong though?
By reading your last proposal, I have the feeling you mention
BookmarkKit when in fact you think to some new framework unrelated to
bookmarks management or not restricted to?
If I understand your proposal correctly, I would say it's probably a
little bit complicated if you only consider BookmarkKit in this plan.
Having a single database by user for BookmarkKit is perfectly fine I
think.
And why not model group vs bookmarks (and other organisation aspects)
in term of relationship(s) rather than relying on an external
propertylist?… when you take in account CoreData or sqllite both have
relational support.
Do you have any particular reasons to split bookmarks storage in
several databases (one per application)?
Sorry that I didn't make it clear.
If you compare the AddressesKit and BookmarkKit,
they are doing very similar things.
Both of them has a basic record, either a contact or a bookmark.
Both the record can be store in database.
All the record can be organized in a group,
and a group can contain another group.
This organization can be display in NSOutlineView.
The only difference is the record itself, which is a object.
In this case, we can have a single framework to handle
storage and organization of the records.
Frankly, every application using 3-panel can use this frameworks.
The group display on the left, the record on the right top,
and the content of record on the right bottom.
And because a record is actually a object.
We can have CoreData for storage,
which uses sqlite3 database as backend.
Otherwise, if we start writing the BookmarkKit,
I bet it wiill be very similar to AddressesKit in the end.
Yen-Ju
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
