Elliot Foster wrote: > David Ford wrote: >> It's a great idea, never thought otherwise. My comment should be >> taken to mean, don't reinvent the wheel, take the existing wheel, >> sand it down like new, and refinish it so it's all bright and shiny >> again. > > What if we want a wheel with rubber, rather than just bare wood? > Besides, there is plenty of stuff that can be reused. > Procmail/maildrop would be the most obvious. The mail server won't > change (other than the MDA,) asterisk would work well (as Robert > pointed out,) and we are going to need some new software on the client > side no matter what. I'm just talking about the glue between the mail > server and asterisk.
Procmail doesn't need modified. All you have to do today is enable COMSAT=yes in your procmailrc then tell your biff how to do the notification. Comsat is the network's message notification service, biff is the handler mechanism. example procmailrc, :0 * ^TO_ [EMAIL PROTECTED] { COMSAT=yes ...other stuff } This is a procmailrc solution w/ biff, but not everyone runs procmail so a broad MDA solution is wanted as well. Ideally the end solution should be agnostic from the handheld's point of view. We want the handheld to be able to have a [x] Use SMS for new mail notification, i.e. PUSH email, and not worry about configuring the server to support it. Otherwise this is a hackers only solution and useless for everyone except us. We need to support the protocol that exchange uses since that is very common as well. Not have an option for every type of pushed solution available. Ideally the procmail/comsat/biff solution would result in an SMS notification in the same format as is already implemented for other phones w/ i.e. exchange. > That's exactly what I was saying (notify the handheld of new mail.) I > agree about the reuse of existing solutions, but I don't know of a > single mail server that supports biff/comsat, so I don't think that it > would be very useful to 're-awaken' comsat/biff. We would still need > to modify some portion of the mail server (procmail) in order to > notify comsat/biff. I'm assuming all comsat/biff would do is trigger > the notification to the handheld, so why not do that directly? > > In general, there's no server to patch, just a script that would be > dropped into procmail/maildrop or whatever your MDA is. Sendmail doesn't do comsat internally, it relies on the external MDA/LDA to accomplish it. Postfix comes with comsat service. Qmail naturally is in it's own little world of how things should be done and considers comsat an abomination, but there still exists qbiff. > >> This is what "push" email does w/ exchange when you configure your >> phone to ask for SMS for email notification. > > Right, I said that in my email. I agree with you in how it > could/should be done, but I don't think it would be very useful to use > biff/comsat, as they would be an unnecessary middleman. I think it > would be cleaner to just have a script that someone can drop into > their MDA to trigger a pull from the client. Like I said in my > previous email, it seems the best place to do it, because then they > can filter for specific emails. I don't know if I would want my phone > being woken up by every mailing list email that I get, for example. > Filtering is obviously and definitely good, but the script is just a rewrite for what already exists and is already supported and means that multiple means of notification are already possible. It is debatable whether the phone should be capable of filtering notifications and choosing it's reaction, or being dumb and always reacting to notifications. Personally I think that is akin to a profile just like when to respond to an incoming call. In the end, I would rather have an MDA agnostic solution that uses an already developed protocol for new message notification where the phone controls whether SMS notifies are used or not. I.e. SMS push notifies registered with exchange. If we develop hacker only solutions, the phone will remain a hacker only product and just won't penetrate outside the community. I want a phone that a hacker is drooling over and a phone that is entirely feature functional for my secretary that -I- don't have to muck around on the backend to make everything work. That's an enterprise support nightmare. Right now Win phones and some Palm phones already have the option to enable new mail notifications by SMS. It's rapidly being adopted in smart phones. I sincerely think it's a good idea to incorporate what is already supported as well as all of our make-me-happy stuff with our server stuff that we control like procmail, and it should be as invisible to the end user interface as possible. What we do under the hood is up to us. What we do in front of the user needs to be clean and functional and as agnostic as possible. :) -david p.s. please don't CC me - i'm subscribed to both lists :) _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community