3 ms·

I can't tell if the programmer was using the VoIP mechanisms to allow the app to run continuously in the background, though it does look that the programmer was

by Hoff 16y ago

I can't tell if the programmer was using the VoIP mechanisms to allow the app to run continuously in the background, though it does look that the programmer was attempting that. Apple isn't going to allow continuous background. If your application needs that, then that's likely best an Android application and not an iOS application. And this comment: "It’s just not possible to tell them to hold the chatline, send a Push Message, and resend the text to the app when it comes online…"? That's arguably less of a limit, and more of a potential opportunity. Why not create the servers necessary to do that; to allow off-line IRC, and deliver via push? There are folks already using a similar scheme - bouncers - to do that with existing IRC clients and servers, after all. Package that and sell it, and (if your end-user agreements are clear about the potential for dual-use of the servers) package and sell the feed, too.

bemmu 16y ago
Yep, it's an opportunity, and there's already a certain someone on HN who would already have all the agreements with IRC networks in place too (they usually don't allow multiple connects from one IP address).
Zev 16y ago
Why not create the servers necessary to do that; to allow off-line IRC, and deliver via push? There are folks already using a similar scheme - bouncers - to do that with existing IRC clients and servers, after all. Package that and sell it, and (if your end-user agreements are clear about the potential for dual-use of the servers) package and sell the feed, too. We considered running a service like this for Mobile Colloquy. We ultimately decided that it wasn't worth doing. Too many different IRC networks out there, too much potential for abuse. This page is slightly out of date, but explains our reasoning for not running a bouncer service on our own: http://colloquy.mobi/push.html http://colloquy.mobi/push.html Instead, we host a push server and let people use a bouncer that they host on their own for push. There's support for ZNC, Colloquy and irssi. Plus an SDK-type thing, so any other bouncer with a plugin system can, in theory, work.

by Hoff 16y ago

bemmu 16y ago

Yep, it's an opportunity, and there's already a certain someone on HN who would already have all the agreements with IRC networks in place too (they usually don't allow multiple connects from one IP address).

Zev 16y ago

Why not create the servers necessary to do that; to allow off-line IRC, and deliver via push? There are folks already using a similar scheme - bouncers - to do that with existing IRC clients and servers, after all. Package that and sell it, and (if your end-user agreements are clear about the potential for dual-use of the servers) package and sell the feed, too. We considered running a service like this for Mobile Colloquy. We ultimately decided that it wasn't worth doing. Too many different IRC networks out there, too much potential for abuse. This page is slightly out of date, but explains our reasoning for not running a bouncer service on our own: http://colloquy.mobi/push.html http://colloquy.mobi/push.html Instead, we host a push server and let people use a bouncer that they host on their own for push. There's support for ZNC, Colloquy and irssi. Plus an SDK-type thing, so any other bouncer with a plugin system can, in theory, work.