[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 12:47:06 -0600
On Mon, Mar 28, 2011 at 10:16 AM, Barrett <barrett666@xxxxxxxxx> wrote:
>
> Hi all,
> when i released the latest pre-alpha build of Caya, there was a discussion
> about the integration of caya in Haiku.
> I'm thinking to propose for gsoc an API that allow integration of people
> files into Haiku applications.
> This is the pratical use scenario :
>
> You open an im application, caya for example, and then add a contact in your
> jabber account.
> The API takes care of creating a people file into a standard directory
> (/boot/home/people) with the informations
> provided by the "client" app (caya). Then you open the haiku's mail app, and
> you'll be able to send a mail to the contact added by caya.
> To avoid duplications, the system will see as "global contacts" only people
> files copied into the mentioned directory.
>
> I'm asking if would be acceptable for gsoc a project like this :
>
> * Caya modifies to make it an optional package
> * Mail gui refactoring
> * Allow to see mails in tracker (?)
> * Implementation of the contacts integration API
> * Changes needed in mail app and caya to support the new api
> * mail app bugfixing and bug-hunting
> * Make a little contacts preflet
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.
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?
>
>
>
> For example, (just an idea) there may be two classes the first, BPeople
> (BFile subclass) will allow to abstract a people file and make ordinary
> operations on it. The second, BPeopleRoster (derived from BQuery) that will
> allow to see system's contacts and select them using the functionalities
> provided by the BFS.
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). 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.
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.
>
> It's only a draft, i hope that you will like the idea...anyway thanks for
> your time!
I like this idea, and I think it would make a neat GSoC project. As
far as the Mail stuff goes, I'm not familiar with that part of Haiku,
so I won't comment there (maybe Clemens has something to say?).
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.
--Alex
Other related posts:
