Notification.data limitations

[beverloo]

I've got two thoughts on Notification.data.

1. Let's limit it to persistent notifications. Since there are no onshow/onclose events anymore it doesn't add any value to non-persistent ones.
2. Do we want to impose a maximum size for the data payload? I'm hearing the theoretical concern of people storing loads (>megabytes) of data in there.

I'm not a fan of arbitrary limits, but it does make sense to do so in order to prevent abuse. I expect our implementation to impose a limit of sorts, but am not sure yet where to draw the line.

[annevk]

I rather not impose limits. Developers already have to deal with unpredictable OOM errors elsewhere.

If we only expose this to service workers, I guess we could add PersistentNotificationOptions and move this attribute there? Was that your thinking?

[beverloo]

I think such a split may make sense in either case.

Having thought about it a bit more, we can support .data just fine for non-persistent notifications as well. There's much less point to it, but let's not branch in the spec for this yet.

Since the data is linked to the lifetime of the notification and (at least in our implementation) tied in to normal quota management stuff it should be fine.