Integrating with email

[GoogleCodeExporter]

I do not know if main feature requests should be posted here, but I do 
think it is important.
If you want the Wave protocol to slowly replace Email, it needs to be 
backward compatible!

You should be able to send/receive emails from Google Wave (or any wave 
site). The system would basically send 2 version of the wave. A "wave" 
version, and an "email" version. The same way we do plain text / html 
currently for email. So we would add an email header including a reference 
to the current wave, so if the recipient is using a wave-compatible 
service, it would know to switch to wave. Otherwise, if it does not 
understand the wave header, it would just ignore it and use regular email.
Something like that.

Because seriously, I don't wave picking anytime unless you help people move 
gradually away from email.
Right now I have a lot of friends with wave, but I don't use it because I 
know they check their emails wayy more often than their wave account.
I do the same. So it all needs to be combined.

Original issue reported on code.google.com by natha...@makemeheal.com on 1 Dec 2009 at 1:03

[GoogleCodeExporter]

sorry for the typos:
Because seriously, I don't see wave picking up anytime unless you help people 
move 
gradually away from email.
Right now I have a lot of friends with wave, but I don't use it because I 
know they check their emails waaayy more often than their wave account.
I do the same. So it all needs to be combined in one service.

Original comment by natha...@makemeheal.com on 1 Dec 2009 at 1:06

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Nathan,

This is a hotly discussed topic, and there are a number of approaches this 
could take: 
e.g. full email integration or email reminders. We are working on this, and I 
believe 
there are a few robots out there on googlewave.com that attempt to do this. 
I'll leave 
this bug open so that you, or someone else on this list feels motivated to 
write 
something for FedOne :)

Original comment by joc...@google.com on 1 Dec 2009 at 1:10

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

With regards to mail and fedone, I believe the best option would be to move the
integration to below the agent level and build it directly into the server 
itself.

Ideally it would take the form of an SMTP engine which would then feed the 
email into
FedOne which would translate the email structure into a wave structure and vice
versa. This of course leads to the next thing though: persistance.

Any email->wave integration into FedOne is going to need perisistance

Original comment by JamesRPu...@gmail.com on 1 Dec 2009 at 1:18

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I disagree. FedOne is a power of ten easier to install and configure than email 
in it's current state, so even with 
a reasonable jump in complexity it's not unrealistic to expect Wave servers to 
be popping up all over the 
place. Plus, there's also Sails and Pygo. I would prefer a notification design 
that reminded me when a wave 
had updated. This would discourage "lazy-adoption" where organisations email 
wave users rather than using 
waves themselves.

On the flip side, Email Notifications will largely be moot once there are apps 
for Blackberry, Android and 
iPhone which imitate Push Email notifications - and a good desktop client for 
each of the big 6 (W64, OSX, 
*nix CLI, Haiku, GTK, QT).

Original comment by GeekChiq...@gmail.com on 16 Mar 2010 at 6:20

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

So, to summarize there are 3 possible approaches:
- Email notifications.
- Partial support by means of extension.
- Native support - built in SMTP server + UI modifications to the web client.

The first approach is the most disruptive one  - and also is the most risky 
one, since if Wiab fails to gain critical mass - it might be abandoned.
The extension approach - somewhat eases the risk of non adoption, but if the 
extension would not be good enough - some might get frustrated and project 
those feeling on Wiab as a whole.
The third approach aims for fast adoption by the "best" consumers - like huge 
enterprises and governments (The SMTP server can be made optional, so basic 
Wiab install requirements would remain unchanged), however such native 
integration lacks disruption.
So, if the Wiab project goal is massive Wave technology adoption with as little 
risk as possible - then I think the best approach would be options 1+2 - i.e. 
Wiab server should have native support for email notifications and official 
email integration extension under Apache license.

Original comment by vega113 on 23 Jan 2011 at 8:47

• Added labels: ****
• Removed labels: ****