Re: [Design] Unified approach to getting data IN and OUT of Chandler

[Mimi Yin]

Ted, Morgen, Bear, Priscilla and I met last week to discuss workflows and UI for unifying how users set up Input and Output pipes for moving data in and out of Chandler. http://wiki.osafoundation.org/bin/view/Journal/DataInOutOfChandler Here is a write-up from our meeting and subsequent discussions. We started off with a high-level brainstorm of all the different protocols (technologies) that could be used for moving data in and out of Chandler. In the near-term we will probably mostly focusing on: + Email + Sharing + File import/export + RSS feeds + Web Services Some interesting issues to ponder: + Can we unify the notion of file import/export with subscribing/publishing shares, rss feeds, web services and mailing lists?  (ie. turn file import/export into persistent file transfer conduits that can detect modifications to files and automatically update data in Chandler accordingly) + How do we communicate this "unified approach" to the user? ++ Have separate menu items for email accounts, subscribing/publishing and import and export...but have them all point to a unified "data pipe" manager UI. OR ++ Have a single menu item that takes you to a unified data pipe manager. + What are some compelling use cases for organizing multiple "feeds" of data into a single collection? (ie. a Project collection that pulls together all RSS feeds and mailing lists relevant to that project.) + What are some compelling use cases for publishing a single collection to multiple destinations (ie. my calendar on both Cosmo and .mac) Mimi On Dec 14, 2005, at 8:54 PM, Brendan O'Connor wrote: On 12/14/05, Alec Flett <[EMAIL PROTECTED]> wrote: Mimi Yin wrote: - What about subscribing to and Setting up Mailing lists. If we had UI in Chandler for users to "Subscribe" to mailing lists, would this be a better "model" for helping users understand that they can "filter" mailing lists into their own collections automatically, the same way they can have separate Inboxes for each email account. I think mailing list subscription is pretty non-standard - there are a few major systems for open-source mail, but I think most are a haphazard set of different combinations of putting "Subscribe" in the subject line, in the body, signing up on a web site, etc. However, opera mail handles this rather well - it seems to identify common mailing list headers in your existing mail (which are also non-standard, but perhaps easier to detect) and creates virtual folders for each mailing list you're on. There's a standard going around that puts metainformation about the mailing list in the headers...  Opera Mail seems to do its indexing via it.  The only other client I've seen aware of it is pine...  OSAF's mailman installation does it, the headers on this email have: List-Id: Design Discussions <design.osafoundation.org> List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/design >, [EMAIL PROTECTED]?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/design > List-Post: design@osafoundation.org> List-Help: [EMAIL PROTECTED]?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/design>, [EMAIL PROTECTED] ?subject=subscribe> I guess it's this rfc?  http://www.ietf.org/rfc/rfc2369.txt Better formalizing this to support automatic subscription and unsubscription would seem to be a logical mechanism to support smarter mailing lists in the future.  (e.g. Deme!  http://groupspace.org !) -Brendan

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design