Sheila Mooney wrote:
> 1) The technical pros/cons/issues for all of these alternatives so then
> we can circle back and evaluate these from a workflow perspective.
So Sheila, you are asking for some discussion about technical issues.
I'll throw out some scenarios and questions to get started...
+ Emailing items to a collection on Cosmo ie: Send a /Event to
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
Example 1: Andi adds his pto to the office calendar using pine
- the subject is "/Event pto next thursday"? the body? (or maybe
"/Item pto thursday" and it figures out eventness from "thursday", as
Ted suggested in another thread)
Example 2: I'm reading my Mail.app email, and I forward the mail with
the office calendar tickets to some collection that I own. Perhaps I tag
the message somehow by altering the subject. "/Tag tickets" (In looking
for this example, I looked at emails I have flagged -- these are the
likely candidates for ones I *really* want in Chandler).
To make this work we need:
- NLP, integrated into the process of the event landing in the
collection (in cosmo? in chandler?)
- The ".osaf" service needs to be able to receive email. Something needs
to process that email and create events that land in cosmo.
Questions:
- How does error handling work? What if Andi sends "/Evt pto thurrsday"?
- Is this the example workflow you had in mind?
- How expensive is this to implement on the service side?
- Is this a cosmo feature or a service feature?
Assumptions:
- The point of this is to work for mail sent from non-chandler email
clients.
+ Drag and drop emails and attachments from other email clients.
Observation:
- one advantage of the IMAP solution is that you can create a rule to
copy items as they come in, vs moving them by hand.
+ Pull down emails that have special headers.
Example: Priscilla sends her docent schedule to me at my osaf address.
Chandler sucks in this email, but ignores my huge inbox (not to mention
the folders containing email from list subscriptions).
Question:
- Can someone elaborate on what advantages this confers from the
implementation perspective? Presumably it reduces the size of the
repository. Any other advantages?
+ Handle a one-time import of an Inbox
Example: I create folder where I put my flagged messages. They get
sucked into Chandler, but if I make edits they won't be reflected in my
inbox.
- I assume this could apply to a particular folder, not just the inbox
- If I keep adding to the folder, does this work? It just imports
new items?
- Do I have to manually cause the import to happen, from a menu?
Example: I create a folder with all of the resumes/related email I
receive for a job posting -- this gets imported into chandler where I
supplement that with info from other places.
Question:
- What advantages does this confer from an implementation perspective?
Smaller repository, avoiding sync?
+ Subscribe / Sync to select IMAP folder(s) ie: Inbox, manage design
list in the desktop.
Question:
- What advantages does this confer from an implementation perspective,
aside from a smaller repository?
+ The desktop as an IMAP client
I'm not sure I understand this one, beyond being the option of just
going for it and implementing an email client. :)
+ The desktop as an IMAP server
Example: I create a rule to copy all flagged items into my chandler
inbox, which can be seen by Mail.app. Some items are reference material,
some items are todo items, some items represent calendar events. When
I'm in Chandler, I triage these, stamp with metadata, etc. Comparing
this to retyping info into omnioutliner by hand while looking at my
inbox, this option looks pretty swell to me.
+ RSS in and RSS out via desktop/web access
Examples?
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
