Sheila Mooney wrote: > Some options for bridging the gap between the desktop and existing email > clients that have came up so far are...
Thanks for maintaining and promoting discussion on this list of options. Here's a few comments about feasibility. > + Emailing items to a collection on Cosmo I like this one; it's got a nice, open interoperability aspect providing pretty general-purpose functionality. Below are a few assumptions about how I'd expect this to work. Emailing an item implies two things to me. 1) the email is sent to a particular recipient, identified by an RFC822 email address ([EMAIL PROTECTED]; obvious but important later); 2) the email is sent through the Internet-standard SMTP store-and-forward fabric (sender sends through their ISP, through zero or more email proxies, to be delivered for processing to a Hosted Service server). I think the "mail server" aspect of the above assumptions put this pretty firmly in the realm of the Hosted Service. I can't think of any reasonable and general mechanism to allow arbitrary mailing to arbitrary Cosmo collections, but for collections in the Hosted Service, that's fully in our control. It's fairly silly to build one's own Mail Transport Agent (MTA), a server which speaks SMTP in a way solid enough to be exposed to the open Internet. There's some standard open source implementations of MTAs, such as sendmail and postfix. I use Postfix for virtually all implementations as it is rock solid with an architecture generalized and modular enough to pull off pretty much any configuration needed. In general, the systems architecture is like batch processing. Each email is a "job" (in batch processing language), and email submissions are queued up and then processed one at a time or in parallel. This chain of "email alias to MTA to batch processing script" I'll call an email robot (other terms welcomed). So I basically assume processing email submission of event items to a Hosted Service collection involves sending to an OSAF server where Postfix is configured with enough custom scripting to implement a batch processing system for incoming email which performs operations found in an email or hands off to another component for further processing. It is possible to carry on an email conversation by sending response email to the (purported) sender asking for additional information (auth, clarify request, etc). Or you can send sender to a web page. All information needed to identify the target calendar, submitter authentication, start/end, event description, etc (collectively called "submission data" perhaps) must reside somewhere in the headers or body of the email content. There are many schemes and methods possible to extract the needed submission data. Often, one would encode the target collection in the recipient address. This is like your proposal address [EMAIL PROTECTED] You could also have a general submission alias and put the target collection somewhere in the body. I focus on the recipient email address because a lot of design points revolve around that: + What are valid recipient addresses to use? + How do addresses map to calendars? (1-1, 1 to many, many to 1) + How are new addresses created? + What information gets coded into the recipient address? Target calendar? Security-through-obscurity? + Is authentication info put into the recipient alias? + Are the addresses temporary or permanent? + What domain name (right-hand-side of the address) is used for the address? + Are multiple domain names or just a single one in use? + How likely is the alias to receive dictionary-attack spam (ie, guessing of addresses)? + How likely is this alias to be published and collected by spammers? It's important to formulate an architecture that is pretty resistant to spam attacks. Who wants spam in their calendar? This is a difficult problem to solve without switching to some non-interoperable methods. Some ideas there: + You can have throw-away email addresses. Use a web UI to create a new temporary email alias. Run a REST/XML-RPC service which allows others apps to create new temporary email aliases before submitting anything. + You don't expect humans to send to the address. You use a very exacting format that only computers can formulate and send. + You expect humans to send, but you use some special (hard to get right probably) format, teach it people, and tell them not to tell others or publish it. You could have a password that needed to be included in the submission, and change it periodically. + You take your SMTP mail server off the "open net" and only take submission from specific upstream mail servers, or specific authorized (possibly encrypted) clients The bulk of logic for the email robot depends on what combination of headers, body, secrets, syntax, and so forth we decide as appropriate for an email submission. Of course, multiple types of submissions may be accepted and it'd be best to design any code to be able to recognize multiple formats. A simple format and implementation are very simple; I prototyped one implementation is a couple hours and 2 kbytes of code (see service-dev email). Essentially everything additional is variations on a theme. For calendar event submission, the core logic is probably the parsing of times (assuming that target calendar is encoded in the recipient email address or something). Here, I'd expect to see Bear's parsetime/itsu library put into play. I'd expect the same basic systems architecture used to implement email submission to work for SMS submission. One would likely purchase a service which provides an SMS-to-email bidirectional gateway and then process SMS messages using email-robot scripting logic. One strawperson model: Users use a web ui to create an email alias to attach to a calendar. They can pick both the left side and the first part of the right-hand side of the email alias. [EMAIL PROTECTED] They pick a low-security password that should be included into the subject of a submission. The subject of any incoming emails become the title of the new event. The start of the message body should be any time phrase identified by parsetime. The rest of the message body becomes the long description. The password is stripped from the subject before use. Another model: The email-to-calendar function is only needed for 1 post or a short period of time. A web ui is used to create a new temporary email alias. That email alias is sent around to the needed parties or used immediately. The parsing of the body happens per the above, though a reference to the target collection is needed somewhere (probably still in the recipient email address). At the appropriate time, the temporary email alias ceases to function. There's lots of other models, and I've gone on for a while. Are there some specific cases you'd like me to comment on for server-side feasibility? What sort of additional questions do you need answered? Sorry if I didn't get to the heart of your questions despite the wordy response. -- Jared _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
