Sources
briandunnington
notification data? Right now, the JSON that is returned only has the
title and text, so there is no way to know where the notification is
originally from.
in adapting my test code to work with GfW, i would like to be able to
register the Source as one of the individual applications (as opposed
to simply registering 'notify.io' or something like that) so that the
end user can control their preferences on a per-Source basis.
Abi Raja
Brian Dunnington
Abi Raja
Brian Dunnington
and that 'icon' parameter is the icon specifically for the
notification, right? if the source name is included, i was also hoping
to include the source icon to use as a fallback if the individual
notification does not specify an icon. or perhaps you can just handle
it behind the scenes and pass the correct value for 'icon' in either
case since notify.io already knows the source icon path as well.
> I agree that the source should be passed too. As for users being able to
> control individual web apps from GFW, that would be good. In addition, the
> authorization notifications from notify.io should be sent too (and then,
> they'd click through to open the notify.io URL in the browser and authorize
> the new web app or could we have an API to authorize directly from GFW
> too?).
in another thread, i think Jeff said that the authorization
notifications would be sent via email, but i agreed that it would be
nice to send them as notifications as well. if there existed an
authorization API, that would be great to use. a simple url back to
notify.io would work too, but then the user might have to log in if
they arent already logged in (in other words, there would be one
additional step to approval).
Jeff Lindsay
and that 'icon' parameter is the icon specifically for the
notification, right? if the source name is included, i was also hoping
to include the source icon to use as a fallback if the individual
notification does not specify an icon. or perhaps you can just handle
it behind the scenes and pass the correct value for 'icon' in either
case since notify.io already knows the source icon path as well.
Because notify.io knows who the source is when sending, it uses the source icon if no notification icon is used.
in another thread, i think Jeff said that the authorization
notifications would be sent via email, but i agreed that it would be
nice to send them as notifications as well. if there existed an
authorization API, that would be great to use. a simple url back to
notify.io would work too, but then the user might have to log in if
they arent already logged in (in other words, there would be one
additional step to approval).
I was afraid to do this, but it makes sense. I'll do this instead of the email for now.
As far as sending the source ... I was going to get to that. Obviously that'll require some changes to the client. I was going to iteratively head towards this ... my first thought was to instead register each source as a notification under the notify.io app in Growl. Do you think this is a decent step forward? Or would it really make sense to have each source as a separate registered app? I don't think I want to support multiple notification types per source yet .. that increases the complexity in several places and seems unnecessary at this point.
Jeff Lindsay
http://webhooks.org -- Make the web more programmable
http://shdh.org -- A party for hackers and thinkers
http://tigdb.com -- Discover indie games
http://progrium.com -- More interesting things
Brian Dunnington
> icon if no notification icon is used.
cool.
> I was afraid to do this, but it makes sense. I'll do this instead of the
> email for now.
i think that if notify.io only sends the authorization notification
once for a single source, it wont be too spammy and will be useful for
most users. if a user doesnt want to authorize that source, they will
never see it again.
> As far as sending the source ... I was going to get to that. Obviously
> that'll require some changes to the client. I was going to iteratively head
> towards this ... my first thought was to instead register each source as a
> notification under the notify.io app in Growl. Do you think this is a decent
> step forward? Or would it really make sense to have each source as a
> separate registered app? I don't think I want to support multiple
> notification types per source yet .. that increases the complexity in
> several places and seems unnecessary at this point.
whether each source is a 'type' under the notify.io 'app' or each
source is its own app, it shouldnt really matter. in either case, the
source information will need to be in the notification data.
personally, as an end user, i would prefer each source to be listed as
their own app, since that is how i would think about them. (in other
words, if i wanted to modify my Google Wave notifications, i wouldnt
necessarily think to look under notify.io - that is just the transport
mechanism at that point and should remain somewhat in the background).
i can also see it the other way though, and there could be collisions
if a user was using some kind of local (or non-notify.io)
notifications for an app and then the notify.io notifications wanted
to 'register' as the same app name.
Jeff Lindsay
Brian Dunnington
> not unique -- hmm).
that problem is bigger than notify.io - Growl* and Growl for Windows
(and, at least the last time i checked, Snarl) all use a string for
the application name as well. nothing stops an app from saying their
application name is 'Firefox' or 'iTunes' even when it is not and
having it step on an existing application. i think the current
solution is to assume that any app that acted as such a bad citizen
would simply be shunned by the user.
* for local OSX apps that specify their application-bundle-id, this
might be a non-issue (i am not 100% sure of the internal workings),
but for all other remote applications, the same problem exists.
Brian Dunnington
one other thing you might want to check - i *think* Growl only allows
you to register the various notification types for an application as a
whole. in other words, i dont think you can add a new source as a new
notification type without re-registering the entire list of
sources/types. but like i said, i am not sure so it would be good to
confirm this.
Jeff Lindsay
one other thing you might want to check - i *think* Growl only allows
you to register the various notification types for an application as a
whole. in other words, i dont think you can add a new source as a new
notification type without re-registering the entire list of
sources/types. but like i said, i am not sure so it would be good to
confirm this.
i believe you might be right, and this would undermine my logic of that being the easiest implementation... i think i'll hold off on that until we get a better idea of what users actually want, and have more experience with the various notifier's app/type model/api.
Peter Hosey
> … would it really make sense to have each source as a separate
> registered app?
Assuming that a “source” is a web app or something, it would indeed.
If you re-register notify.io with the new source's notifications in
addition to all previous sources' notifications, it's going to become
a very long list eventually.
Jeff Lindsay
Brian Dunnington
> work on higher priority items.
Just punt on how the Growl integration is going to work for now, but
you are still going to add the source information to the notification
JSON, right? it will be needed in any event. just wanted to make sure
i understood correctly.
Jeff Lindsay
will go live next time i push to production.