61
edits
Changes
no edit summary
|Feature open issues and risks=Some points that are still completely open to discussion but need a decision before or as part of the "Design" stage here:
* Should IM conversations happen inside Thunderbird (removing the need for the user to have another IM client on his system), or should they happen in the user's default inan external IM client (like http links are viewed in the default web browser)? (In the first case, Thunderbird would connect directly to IM servers through IM protocols, on the second case, Thunderbird would integrate with the IM software installed on the local system to share data.)** Using the default IM client seems like the user already has may be hard because:*** There are lots of different clients out there. Integrating will all of them is impossible.*** All clients may not have a false good idea becauseAPI (if they have one at all).*** Possible security / privacy issues:we can't offer any guarantee on the way IM conversation data is handled locally and transfered over the network by third party IM clients that we don't really know.*** It appears Integrating with the existing IM clients seems like it would save implementation time and could help us ship something sooner... but if we end up having to ship our own stack later, integrating with the default external clients first is a waste of time/resources.** We could pick a small set of clients for each platform and do the integration work only for them:*** There's no guarantee that the clients How would we would like to integrate with select them? (the clients with significant usage from our target usersPopularity? Open-source-ness?) provide useful APIs.*** Possible security / privacy issues: If we can't offer any guarantee on provide a good API and the way IM conversation data integration is handled locally appealing, the teams working on other clients may get interested and transfered over do their part of the network by third party IM clientsintegration work.** Integrating Having some built-in protocol implementations by default doesn't dispense us from having a plugin system for protocol protocols which, by their closed nature, can't be implemented directly (obvious example: Skype).** Using external clients would avoid showing contacts when Thunderbird needs to be restarted for some reason (add-on installs, ...).
* Should IMs go above the current content (the emails the user is reading or the email he is composing) or be contained in some specific area (tab? folder? other window?) where the user would have to go to exchange IMs.
* If emails are shown in a conversation view, integrating in that view the IM conversations that happened on the same subject could give a better overview of the exchanges.
* (assuming calendar integration) While setting up an event, seeing that some of the invitees are online and starting an IM conversation with them could help discuss and find a possible date/time faster.
* (assuming calendar integration) Changing the IM status automatically to 'Do not disturb' during meetings that are indicated by the calendar.
* Collaborative editing: asking someone who's available to proof read an email draft, and discussing the proposed changes in an IM conversation.
|Feature dependencies=* Address book updates to support IM addresses for different networks (?)
