[haiku-development] Re: Working on Caya and Mail app for GSoC
- From: Alex Wilson <yourpalal2@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 28 Mar 2011 16:54:31 -0600
On Mon, Mar 28, 2011 at 4:11 PM, Barrett <barrett666@xxxxxxxxx> wrote:
> 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)
Yes, I considered this. I was mainly thinking of cases where no
dedicated app would exist eg. gmail. It would be nice to have the
ability to open a 'sync' panel in the preflet and press 'sync contacts
with gmail' or 'sync contacts with all external sources'.
>> 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)
That seems like a good list. How do you plan to integrate this with
the People app? Would all the editing of contacts be done by People,
or would you merge it into the Contacts preflet?
>> 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.
I meant that BPerson would hold and own a single BPeopleFile, which is
commonly referred to as composition, not aggregation (sorry). There
would still only be one file per contact.
>>
>> 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.
I think the discussions will be on haiku-commit, if that helps. :)
> 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.
When you make your official proposal (in the melange app), it would
would be a nice insight if you highlight what problems you have
encountered, and specifically how you plan to fix them.
--Alex
Other related posts:
