On 10/4/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
Le 4 oct. 06 à 18:24, Yen-Ju Chen a écrit :
> On 10/4/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
>> By dipping into AddressesKit, I think a possibility could be to move
>> some classes like ADRecord, ADSearchElement, ADMultiValue,
>> ADMutableMultiValue, ADGroup in a separate framework (based on
>> CoreData by default).
>> AddressesKit and BookmarkKit could then rely on this new framework by
>> just providing dedicated classes for their custom model/record
>> objects.
>> AddressesKit offers the possibility to add new storage source (like a
>> DB) with the class ADEnvelopeAddressBook, this could be helpful to
>> have flexible storage sources for this new framework.
>>
>> Is this roughly similar to your idea?
>
> Yeap, that's exact what I want.
> And since the AddressesKit is well rewritten,
> we can just borrow a lot from it.
> We may not need to use CoreData for now if it is not ready.
> As long as we can write the record into something,
> say property list or directly into database,
> it will be fine for now.
>
> So the relationship will looks like:
>
> Applications -> BookmartKit/AddressesKit ->
> a generic kit -> CoreData (optional) -> database / property list
>
> So the AddressesKit will be refactored under this plan.
Great, this a very good plan in my opinion.
My only grip would be about storing group relationship in property
lists, I think it's better to have them expressed in term of database
relations.
Group is something not easy to handle.
If you want to store the group in database relationship,
you need a database for one group,
which create a lot of overhead.
And a group may contain records and groups.
A database is not designed to store different type of data.
A typical way to store a group is to store all the records belonging to
the group in a place (file), or the referenes to the records while all the
records are in a database.
But it is not a best situation for indexing and searching.
The best situation for indexing and searching is something like tags.
Every record has tags on it so that it is easy to find which records
belonging to which group.
Otherwise, we need to go through all groups just to find out
which records belongs to which group.
It is surprising that iTunes does store all records and groups
in a big property list.
I assume they figure that is the best way to deal with a lot of records
and groups, say thousands of songs and hundred of playlists,
and has less overhead.
So I believe there are so many ways to implement groups and records.
But the simplest way so far is to put all records in a place,
either property list or database.
Then groups store the references to the records,
although it is a little tricky to refer to other groups from a group.
For easy indexing and searching,
we can also tag a record when it is added into another group.
But again, when group A is added into group B,
all the records in group A have to be taged as group B
and as any group which has group B.
It may be very tricky.
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
