Odd Qi resume troubles
I've tried to use Qi a couple of times with Om2008.12, SHR, and Om2009. No matter which distro I have the same resuming from a suspend problem. The screen will be upside down and backwards. I'm pretty sure it's Qi because I don't have the problem with uboot. Am I the only one with this problem and is there a fix? - Elliot ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email Push Service :) smtp+dnotify+Asterisk+... :)
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? 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. As in, there is already a well established network service designed to do this, let's not be mucking around with making new scripts and patching servers to execute scripts. Let's simply re-awaken the use of comsat/biff and update that software to modern needs - i.e. SMS on receipt of new mail that pushes the notification to the handheld and then the handheld can immediately respond as the user wants. That prevents the need of having an established IDLE connection all the time that needs to periodically poll. (mobile phones need to poll even in IDLE because more often than not they are behind a NAT gateway which will drop idle connections) 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. 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. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Email Push Service :) smtp+dnotify+Asterisk+... :)
Redvers Davies wrote: On Tue, 2007-01-30 at 23:49 -0800, Elliot F. wrote: Google talk has a persistent connection between the client and the server. With a persistent connection, pushing data is pretty easy. We have to use a persistant connection as most GSM networks use private address space and NAT. This means we can't just throw a UDP packet at the phone. I realize we can't make unsolicited connections to the phone, but I would disagree with the we have to use a persistent connection statement. The best point that Robert made in his original post was that there are out of band methods of alerting the phone that a new message is available (call from known number or SMS message.) As far as I know, this is how current push email systems work. IMAP is an asyncronous protocol. The purpose of the IDLE command is JUST to spot the IMAP server tearing down the connection. IDLE is not a poll, if configured correctly the IMAP server will just spit out notifications on the existing TCP stream as and when mails come in. I'm not sure what you mean by IMAP is an asynchronous protocol, but I never said that IDLE was a poll. It's also not there JUST to spot the IMAP server tearing down the connection. IMAP IDLE is 'true' push email (at least the earliest I know of.) IMAP maintains a persistent connection to a server (see my comment above re: pushing data is easy with a persistent connection.) The server can then push messages via the established connection. For those interested: http://www.faqs.org/rfcs/rfc2177.html Another good summary of the whole topic is here: http://www.isode.com/whitepapers/imap-idle.html My whole point is that maintaining a persistent connection between the mobile phone is (in my opinion) not efficient, not as easy, and more prone to error than using some sort of out-of-band notification. I'd be happy to see all implementations, though. There's not reason why it needs to be done just one way. Depending on the user, it may make more sense to do it one way over the other. If anyone wanted to implement the openmoko stack as a hardwired application (using VOIP for making/taking phone calls, for example), then the persistent connection would make much more sense. I think I'll leave this thread now, as it doesn't seem to be bearing much fruit. I look forward to the SDK and the phone, though, as this is a very promising feature (as anyone who is a blackberry addict can attest.) ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Email Push Service :) smtp+dnotify+Asterisk+... :)
David Ford wrote: Elliot F. wrote: Or you could simply modify the mail server to trigger a script when a message is delivered, rather than having to poll each directory/file. A procmail/maildrop filter would be one way to implement it easily (allowing you to filter for messages from specific people, to certain folders, etc.) To be honest, this is an ancient idea. grep comsat /etc/services New mail notification has been around since the dawn of mail itself. Look for comsat in 'man procmail' and review 'man comsat' and biff, etc. Of course it's an ancient idea, but that doesn't mean it's not a good idea. Biff/comsat were local notification or notification via hostname. Local notification of mail delivery is easy. All modern biff replacements that I know of function by polling a mailbox (POP/IMAP) every N seconds/minutes. This is not efficient/practical for a cell phone. The closest thing to push mail as a semi-standard protocol is IMAP's IDLE extension, or Exchange's proprietary protocols. Both of which require a persistent connection. Again, not practical/efficient for a cell phone. It's an old idea, but it's still very much a good idea with no clear solution in the mobile space, and Michel came up with a very good idea for notifying the device. It's an obvious need and it would be great if we could fill it. I'm not sure what you were trying to add by saying it's an ancient idea. Care to explain further? ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Email Push Service :) smtp+dnotify+Asterisk+... :)
Andreas Kostyrka wrote: * Elliot F. [EMAIL PROTECTED] [070131 03:45]: Or you could simply modify the mail server to trigger a script when a message is delivered, rather than having to poll each directory/file. A procmail/maildrop filter would be one way to implement it easily (allowing you to filter for messages from specific people, to certain folders, etc.) With the specific problem that you have nowhere to push to. Normal GPRS has to live with a strict NAT firewall. That's (and because of billing aspects) probably why pushmailservices usually have their own APN. My point was that the mail server (MDA, as I was suggesting with procmail) would trigger the event that notifies the phone client that a new message arrived. I wasn't suggesting that the server is going to connect to port 1025 on the phone and deliver via SMTP. :) The client would be notified and pull any new messages. I really like this idea. As I understood it, many previous push email services relied on sending an SMS message to the phone, which made the phone perform the actions that you describe (get new mail.) However, hooking in directly to the incoming call would save the money that SMS messages cost. Nope, real push mail is just that. It just needs support from the network. Or a special low bandwidth protocol to poll. E.g. one of the highest prices mentioned here was 1KB at 3cent (CDN). Still, one could design a protocol that sends one I'm alive byte say 30 minutes, and listens all the time for an you've got mail byte. Don't forget protocol overhead. UDP header alone is 8 bytes, plus IP header, and it doesn't get much more lightweight than that. Of course, you won't know if the packet actually made it to the destination. :) That would mean, a standby cost of 1KB every 20 days. That's assumming a keep alive is needed every 30 minutes. Guess it would make sense to support an additional mode where (for the home network) the phone senses the right standby before the NAT firewall kills our TCP connection. (But that should be manual, because the reconnects needed during probing will use up some KB) Why bother polling at all? You would be repeatedly starting up or maintaining a data connection when there may/may not be a need. I'm not sure, but I would assume it would also use more power while maintaining the connection (due to the radio.) Why not use some sort of method to notify the client when there is a message (via SMS or call from a known number)? I'd be interested in seeing/hearing what hooks/services will be exposed. Will the incoming calls trigger a dbus message or something similar? 5. skript2 will switch on GPRS and fetch the new mail via POP or IMAP and after downloading the mail it will inform the user (depend on the dailingprofil) So did I missed something? Why is push services and the software for this such a hype? Yeah, the original poster missed the fact, that in most billing plans switching off GPRS is expensive. E.g. GPRS is billed usually in blocks of 10/100KB (this applies btw also to xMB included plans in Austria). So switching off GPRS while you've fetched a 2KB email is plain stupid. There's no reason to be insulting. Please try to be respectful and educate rather than insult. Besides, I don't think turning on GPRS and/or leaving it on to poll is any better. You're wasting battery life and data with maintaining a persistent connection/polling. Also, I believe that voice calls cannot be received when a data connection is active. Please correct me if I'm wrong. Getting a call from a known number and not having the phone ring is free in most places. It's free, doesn't take much battery life, and doesn't spend data by polling. That is the best part of Robert's idea. Because it's very handy, and very well integrated. Blackberry and Windows Mobile (or whatever it's called) have the pieces at both ends that are required for the integration. Yeah, and the support of the network providers ;) Which isn't strictly necessary. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Email Push Service :) smtp+dnotify+Asterisk+... :)
Google talk has a persistent connection between the client and the server. With a persistent connection, pushing data is pretty easy. Jae Stutzman wrote: I have been playing around with MGTalk which is a java midlet for google talk. It has some sort of push email notification that works with my gmail account. I have not looked any deeper but maybe using a modified jabber server one could create an open source push email server. Although it is nice to know when i get a new email (even when the app is idle). Jae ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
