[Dev] Re: [Design] Chandler as an email client? Another idea...

[Lisa Dusseault]

I agree with this and I think it's a nice general statement of one of 
the first challenges for a full PIM, that of getting *all* the P.I. in 
one place first for centrality, a complete system being the first step 
for a trusted system.  I would just like to be parsimonious in how many 
things we have to implement to achieve that completeness.  The more 
moving pieces, the more bugs, and in this case, more system management, 
a burden on the user even before encountering bugs (and firewalls, and 
more).

lisa

On Jan 13, 2006, at 5:16 PM, Andi Vajda wrote:

>
> On Fri, 13 Jan 2006, Mimi Yin wrote:
>
>> I believe Lisa may be referring to the one-item in multiple locations 
>> data model incompatibility.
>
> So what ? To IMAP it'd just look like the item is in one location, 
> even though it isn't.
>
> I find Morgen's idea very intriguing....
>
> Its benefit is not the IMAP part, it's the workaround-the-lack-of-UI 
> part. Being able to stuff chandler with my email data, yet 'do email' 
> from whatever email client I choose is an exact fit for me for the 
> time being.
>
> I'd argue that implementing the right email UI is considerably harder 
> than doing what Morgen suggests, especially given that our focus still 
> is going to be elsewhere for 0.7.
>
> Why not extend Morgen's idea to IRC ? I'd love to be able to have IRC 
> go through Chandler so that I can later search IRC logs, yet use 
> Colloquy until Chandler gets an IRC UI. Likewise with RSS ? etc.... ?
>
> Basically, I interpret Morgen's idea as making Chandler a proxy for 
> all sorts of data that Chandler can index, log, serve and even render 
> ... at times.
>
> It would make Chandler much more useful beyond a calendar much sooner 
> since implementing these proxies is vastly easier than the UI to 
> render all these kinds of data.
>
> Andi..
>
>>
>> On Jan 13, 2006, at 4:10 PM, Morgen Sagen wrote:
>>
>>> On Jan 13, 2006, at 4:04 PM, Lisa Dusseault wrote:
>>>> I believe there are far easier ways of getting the exact features, 
>>>> and definitely the benefits, of what you suggest - without doing 
>>>> something so unaesthetic (and incompatible with our data model) as 
>>>> an IMAP server.
>>>> Lisa
>>> Does your email client speak some other protocol, Lisa?  :-)  I 
>>> don't see what's incompatible here.  We're already stamping emails 
>>> as tasks.  This is essentially another way to do that.
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>> Open Source Applications Foundation "Design" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/design
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design