[haiku-development] Re: Working on Caya and Mail app for GSoC
- From: Barrett <barrett666@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 29 Mar 2011 00:11:56 +0200
Hi alex, thanks for suggestions : )
I think it would also be cool if the BPeopleRoster you mention below
> or the contacts app allowed for contact syncing addons, so that for
> instance, I could sync my gmail or facebook contacts. Of course, Caya
> or similar apps would do automatic syncing on their own. I think
> developing one of these addons would probably be overkill for the
> summer, but support for them would be a reasonable goal.
>
It seems an interesting feature, maybe an addon API is an overmuch, would be
better to leave to the apps this task? (by providing the needed
class/methods)
I'm curious what all you would want to have in the contacts preflet,
> since this could affect the time required for your project. I think a
> duplicate contacts merger might be one handy function, what other
> functionality are you thinking of?
>
I'm thinking to a simple preflet, with the most essential features :
* Allow add / see and modify contacts in a simple and fast way
* Attributes editing
* Contacts merge feature
* Simple but powerful search mechanism
* Allow to make groups of contacts
* Contacts sync settings
(feel free to suggest other features)
I like the idea of some custom classes, but aggregation is probably a
> better model than derivaton here. For instance, BPeopleFile could
> derive from BFile (with some methods providing convenient/abstracted
> access to the file attributes eg. SetPhoneNumber()), while a BPerson
> class could aggregate BPeopleFile, as well as providing higher level
> functions (eg. parsing/manipulating the BPeopleFile attributes beyond
> simple reads and writes).
>
I like the idea of the BPerson...but a question is natural : could be messy
to have many people files per one BPerson? Personally, i don't see the
motivation...what are the advantages of this approach?
If i add you as contact in my contact list, i want to have all informations
about you (your im contacts for example) into one file.
> If new classes were added, such as
> BPhoneNumber, BAddress, etc. then BPerson could deal with those
> directly, converting them to strings and so on to be passed to the
> BPeopleFile.
>
+1
Similarily BPeopleRoster could hold a BQuery, but I don't think it
> should be derived from BQuery, as the interface it should present
> would be more high level, and centered around BPerson objects.
Your correction is right, it was just to underline that the class will use
our query system internally : )
> P.S. I think there was discussion of a contacts/people API while the
> People app was being refactored, if you search through the list
> archive you can probably find these emails, maybe they will give you
> some inspiration.
>
thanks...i'm trying to find them with no results...tomorrow i'll try to make
a more deep search.
The first thing I care, is to make something that work better. I remember
how frustating was to use im_kit and how many problems it has with contacts
duplications and so on.
Regards
--Dario
Other related posts:
