Actually, this is an open point of discussion. There are those that
think that users are pretty attached to their existing email
clients and they aren't going to switch to Chandler for reading
email. Also, providing a rich experience for reading/writing/
storing email is a significant amount of work.
One of our key challenges is that since email is a major input into
the user's life, we need to be able to process those inputs. Even
if we did create our own email functionality inside of Chandler, I
still think we have to think about how to solve the problem of the
user who wants to continue to use her own email setup and use
Chandler to triage everything. We need that bridge from their email
to the Chandler ecosystem (and that's what this topic is all
about! :-)
I guess I just took for granted that one of our end goals was a
complete replacement for people's current email clients.
I think our long term goals should be as ambitious as possible and I
hope that one of our long term goals is a full email client
replacement. I assumed Sheila's email was more about short term email
in Chandler, and on that I agree that we should be trying to
integrate with existing clients rather than trying to replace them
while I do believe it is important that we have enough of our own
email functionality in Chandler that we can show off the other
integrated features that tie in to email as an input and
communication medium. Email is just too integrated a part of peoples
lives that we can expect them to move completely to Chandler for
email unless we have everything they already use, but we'd loose out
on a lot of valuable users if we waited to try and attract them until
we were totally finished with email in Chandler.
-Mikeal
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design