[Feature Request] Pager Use Case

An iPhone client for Growl available on the App Store.
aeto
Harmless
Posts: 2
Joined: Tue Jul 14, 2009 11:36 pm

[Feature Request] Pager Use Case

Postby aeto » Wed Jul 15, 2009 12:56 am

While a bunch of the existing feature requests talk around this, I thought I'd mention my ideal use case, and the set of things which would be needed to make it work.

The company where I work allows us to establish our personal phones as pagers, for use when critical systems fail. As much as I love the iPhone, the SMS tones simply aren't loud enough to ensure they wake me up. Thus, the requests for things like "priority-based sounds" and "longer/louder sounds" are VERY valuable for this use case. Just generating a "pager-pitched" sin wave which beeps twice a second for a few seconds would be enough, and you can do that yourself without any copyright issues. :> Any chance we could upload our own sounds on the web site and select those per message? I'd pay an extra annual fee or similar for the ability to do things like that.

The other thing which would be VERY useful, but I've not seen here yet, would be some way for sufficiently high priority messages to repeat until acknowledged. That's one nice things most "real" pagers have over any SMS device I've yet seen; they don't shut up until you actually read the message they have for you.

One other thing which would be great, but I also understand could draw an annual subscription or similar would be an email gateway; if I could just send email to <device key>@notify.prowl.weks.net (or similar), I think you could see a whole new class of user...

I've been hoping for an app like this, and am really glad to see what you've got out there now. As a user of Adium and Growl, I have to admit, I'm glad to see who wrote it, too. :>

User avatar
zac
Cocoaforge Admin
Posts: 1518
Joined: Sun Mar 27, 2005 3:19 pm
Contact:

Re: [Feature Request] Pager Use Case

Postby zac » Wed Jul 15, 2009 1:03 am

aeto wrote:While a bunch of the existing feature requests talk around this, I thought I'd mention my ideal use case, and the set of things which would be needed to make it work.

The company where I work allows us to establish our personal phones as pagers, for use when critical systems fail. As much as I love the iPhone, the SMS tones simply aren't loud enough to ensure they wake me up. Thus, the requests for things like "priority-based sounds" and "longer/louder sounds" are VERY valuable for this use case. Just generating a "pager-pitched" sin wave which beeps twice a second for a few seconds would be enough, and you can do that yourself without any copyright issues. :>


I plan to add priority-based sound choices in the next release.

Any chance we could upload our own sounds on the web site and select those per message? I'd pay an extra annual fee or similar for the ability to do things like that.


The sounds are inside the application bundle, and are required to be there by Apple. It wouldn't be possible to provide custom sounds for these notifications without adding them to the bundle.

The other thing which would be VERY useful, but I've not seen here yet, would be some way for sufficiently high priority messages to repeat until acknowledged. That's one nice things most "real" pagers have over any SMS device I've yet seen; they don't shut up until you actually read the message they have for you.


This is an interesting idea. I will think about a decent way to do it if possible, but perhaps whatever is generating such emergencies should continually generate until they're fixed.

One other thing which would be great, but I also understand could draw an annual subscription or similar would be an email gateway; if I could just send email to <device key>@notify.prowl.weks.net (or similar), I think you could see a whole new class of user...


I've been thinking about this, but I think the Prowl API adequately covers the needs for this, so I am choosing to focus my efforts there instead.

I've been hoping for an app like this, and am really glad to see what you've got out there now. As a user of Adium and Growl, I have to admit, I'm glad to see who wrote it, too. :>


Thanks. :)

aeto
Harmless
Posts: 2
Joined: Tue Jul 14, 2009 11:36 pm

Re: [Feature Request] Pager Use Case

Postby aeto » Wed Jul 15, 2009 1:23 am

This is an interesting idea. I will think about a decent way to do it if possible, but perhaps whatever is generating such emergencies should continually generate until they're fixed.


I agree in principle, but...

If I try to use this for a paging application, I need to wedge it into an existing infrastructure. Unfortunately, the only thing this infrastructure is capable of is triggering an event when a ticket is filed, not over and over until I respond to it. I agree; it sucks. While I'm in a position to likely get new sorts of actions added to a ticket, I'm not sure I'm in a position to get that sort of change made. The honest truth is that to make this work, I'll probably have to write an email client top run on our local machines and just send the API call myself; easy enough to do... (I've already written a Java app to send messages; very nice, easy to use API, I have to say.)

That being said, if one of the sounds was *really* long (like 2 minutes), it would accomplish the same purpose. The Apple mobileMe "find the phone" thing does this with a really long sound, and if you hit the close button, it shuts it up. I assume the same would be true for other notification sounds?

Thanks again!

Mike

User avatar
zac
Cocoaforge Admin
Posts: 1518
Joined: Sun Mar 27, 2005 3:19 pm
Contact:

Re: [Feature Request] Pager Use Case

Postby zac » Wed Jul 15, 2009 1:41 am

I agree in principle, but...

If I try to use this for a paging application, I need to wedge it into an existing infrastructure. Unfortunately, the only thing this infrastructure is capable of is triggering an event when a ticket is filed, not over and over until I respond to it. I agree; it sucks. While I'm in a position to likely get new sorts of actions added to a ticket, I'm not sure I'm in a position to get that sort of change made. The honest truth is that to make this work, I'll probably have to write an email client top run on our local machines and just send the API call myself; easy enough to do... (I've already written a Java app to send messages; very nice, easy to use API, I have to say.)



The goal is to make the API as easy as possible, so that's good.

That being said, if one of the sounds was *really* long (like 2 minutes), it would accomplish the same purpose. The Apple mobileMe "find the phone" thing does this with a really long sound, and if you hit the close button, it shuts it up. I assume the same would be true for other notification sounds?


I believe Push maxes out at 30 seconds for playback.

User avatar
zac
Cocoaforge Admin
Posts: 1518
Joined: Sun Mar 27, 2005 3:19 pm
Contact:

Re: [Feature Request] Pager Use Case

Postby zac » Mon Dec 28, 2009 7:48 pm

Since I added API keys, the ability to add an email gateway is not a lost idea in my mind. It's definitely in the short term plans.


Return to “Prowl”

Who is online

Users browsing this forum: No registered users