Revision history for pushbullet-types
0.4.0.0 -- 2017-08-01
bodyfield of link pushes optional. Many channel pushes do not include a body, but only the URL and the title.
Pushparsing. Push sender and receiver information are factored out into separate datatypes, and parsed as a whole. Either you have a full sender (either a client or a channel) or you don't have any of its fields. Same applies to receivers, except that only clients can be receivers, and don't have names. This fixes a bug where pushes sent by channels could not be parsed, since such pushes omit certain fields, such as
0.3.0.0 -- 2017-07-29
PushEphemeralnow supports the
targetsfield, which allows to more faithfully parse clipboard synchronization messages in the realtime event stream.
Ephemeralare now derived.
- Missing device-related datatypes and constructors are now exported.
- Values commonly used by PushBullet for the DeviceIcon type now have a bunch of constants exported for them.
- Aeson version upper bound is now higher; this version of pushbullet-types will now build with Stackage resolver lts-9.0.
- Misc code cleanup.
0.2.0.0 -- 2017-04-30
- Some fields in
PushDataare now made optional, since the objects received from Pushbullet may have them missing.
- A minimum value for
PushbulletTimeis added. This is just zero seconds since the POSIX epoch.
- Ephemerals are reworked. Now
Ephemeralactually has one constructor per ephemeral type, and the previous constructors of
Ephemeralare moved into
Ephemeralnow has a constructor for tickles and nops. Only push-type tickles have a dedicated constructor in
0.1.0.0 -- 2017-02-20
Define the following core types:
Push-- messages used internally in Pushbullet.
Ephemeral-- messages sent directly into the live event stream. These have a multitude of uses, e.g. sending SMS via a phone or seeing whether notifications have occurred on a device.
Device-- representation of a device.
User-- representation of a user.
Permanant-- this is an undocumented type in the Pushbullet API. Notably, SMS threads and messages are permanents.
Some of these types come in two flavors:
Existing. This is
signalled by a type index coming from a datakind.