Brian Moseley wrote: >> Questions: >> - How does error handling work? What if Andi sends "/Evt pto thurrsday"? > > a bounce message?
I think with what Katie outlined, for that subcase, it'd be Chandler which would be doing the first NLP of the submitted string (maybe by submitting to Cosmo raw and then having Chandler sync). I hadn't considered that model previously; I wrote about a server-centric model recently. I like the "full featured"-ness that having Chandler itself do all the parsing of the submitted string. However, that also seems to require some pretty good authentication be layered on top of plain email. Not an easy problem. On reflection, I believe server-side processing and the use of Atom or CalDAV to update Cosmo as Brian suggests is probably the most attractive route with few drawbacks. >> - How expensive is this to implement on the service side? > > probably not terribly so... Overall low. Perhaps 5 requests/second on a $3k server assuming NLP is running on the server and is very expensive, computationally. The workload distributes nicely across multiple boxes; the operation is stateless near as I figure and can have a small set of servers dedicated to email submission processing. >> - Is this a cosmo feature or a service feature? Ooo, ooo, me, me! :) Architecturally, as you might guess, I favor layering this functionality by placing it outside Cosmo. It's a perfect consumer of Cosmo sharing services and a fine example of how one can start to build network services on top of other network services. I see every reason to take advantage of lower effort provided by a Python implementation and the parsetime logic, but the truth is that it shouldn't matter what the implementation is; it's enormously useful to be able to replace it later. A lightweight batch processing engine can integrate multiple components and technologies, so it needn't be consider an either/or thing. I'm open to any advantages we can identify from a tighter Cosmo coupling, though; I'll keep an eye out. > i can imagine shipping plugins for a few popular mail > servers that do this... Hmmm, not sure what such a plugin would consist of. I think the proper protocol to forward emails into Cosmo, should it be necessary, is SMTP. It would then be restricted to localhost or the local upstream MX. I strongly agree with Brian that having Cosmo's SMTP exposed to the world is a headache we don't need. And I'm likely to protest at the mind-boggling deployment interaction of Cosmo servers partitioned by user for one purpose and trying to get emails to go to only the right Cosmo server for processing :) Katie wrote: > - Is this the example workflow you had in mind? One issue that your email highlighted was that I have thought primarily about submission of events to a calendar. The opening statement mentions "Email items". I know how to submit an event already, say through CalDAV per the prototype, but the general concept of item I don't know quite how to get into Chandler, at least through Cosmo. Perhaps this is sharing format material. Perhaps we just queue up email submissions for Chandler to retrieve in original form for full processing. It's feasible and not too expensive, perhaps through IMAP or WebDAV, to store up the messages in raw form as they come in, for Chandler to download and place on the dashboard for manipulation. We could poll for new items, or maybe provide an always-on pub/sub event passing framework, note new emails on a private channel, and implement push. If Chandler learns how read IMAP more, possibly a folder sync, then users could use their own email accounts as submission addresses, and Chandler would process the new events when it processed the rest of your email. This would provide a more fully-featured Chandler semantics since Chandler would again be reading directly. > - How does error handling work? What if Andi sends "/Evt pto thurrsday"? Any regular email robot can send responses as part of its batch processing workflow. This is subject to spoofing and spam-related attacks by the way; in general it is questionable to respond to any random From: line sent to an address. I've generally seen that when people submit things via email they are comfortable getting a response via email too (success or fail or possibly user-selectable). -- Jared _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
