Talk:Thunderbird:Future of Thunderbird: Difference between revisions

No edit summary
Line 6: Line 6:


* So I agree with lots what you posted, I wouldn't suggest to tie it to one server product, but use existing standards if possible. [[User:Eddyn|Eddyn]] 13:01, 29 July 2007 (PDT)
* So I agree with lots what you posted, I wouldn't suggest to tie it to one server product, but use existing standards if possible. [[User:Eddyn|Eddyn]] 13:01, 29 July 2007 (PDT)
== Roadmap suggestion: Focus on backend, features will follow ==
I would like to suggest an outlook (sorry about the pun) which is almost diametrically opposed to what I've been reading people say on talkbacks, forums, etc.
Most people's suggestions seem to be about 2 things: Fix their personally-favorite UI bug :-)  and add new features - calendaring, instant messaging, etc. I believe that as long as you are just two full-time developers, this is not a good idea. I find that the current tb development community is overstretched as it is. With more resources, feature-set expansion is more reasonable.
The alternative, in my view, is to focus on improving tb's back end:  disentangle back-end API from the front-end (e.g. the address book, in which AFAICR you have to interact with the address book window to add/remove/manipulate entries), add support for more mail storage formats (maildir, databases, maybe even other mail clients' formats), rework some older and cruftier parts of the code (like libmime), allow for real manipulation of messages in code (i.e. have message objects rather than just message header objects), expand the concept of a message to accommodate future work with instant messaging or forums-via-mail-client and other such modes of communication and interaction, create a more powerful and more versatile filtering framework, et cetera. And let's not forget better code and interface documentation!
I think the focus on 'enabling' work, backend improvement work, should allow more people to get involved with core tb development in general, expand the possibilities of what can be done with extensions, and perhaps even lure people who are now only extension developers to get involved with core development. These last few goals are what I wish to stress the most - even if you disagree with some of the foci I listed in the previous paragraph.


== A new vision and roadmap for Thunderbird. ==
== A new vision and roadmap for Thunderbird. ==
Line 12: Line 22:
# Integrating serverless Instant Messenger retroshare.sf.net to Thunderbird
# Integrating serverless Instant Messenger retroshare.sf.net to Thunderbird
# Creating a adress book in Thunderbird, which has: emailadress, retroshare-key fields for each contact (copy out line).
# Creating a adress book in Thunderbird, which has: emailadress, retroshare-key fields for each contact (copy out line).
# creating the online-contact box in the left menue as a contact list for Thunderbrid email, users are offline or online and can be messaged or emailed. So there is no need for a buddylist, it is just the contacts adressbook of Thunderbird, which appears in the write Window and under teh folders in the main window left.
# creating the online-contact box in the left menue as a contact list for Thunderbird email, users are offline or online and can be messaged or emailed. So there is no need for a buddylist, it is just the contacts adressbook of Thunderbird, which appears in the write Window and under teh folders in the main window left.
# Make a Thunderbird wizard, which picks up email-pop, retroshare cert_user.pem file OR creats an account for retroshare serverless IM.
# Make a Thunderbird wizard, which picks up email-pop, retroshare cert_user.pem file OR creates an account for retroshare serverless IM.


These five steps to a new Thunderbird future combine both:
These five steps to a new Thunderbird future combine both:
20

edits