bicycle |
28 min
|
4.9 miles
|
bicycle |
I'm implementing a draft of this in Aperture right now. Here is the current API.
Every entry now includes a unique system ID, meant for internal identification of the item (not global identification). This is returned in the timeline response as the parameter _id
, and there is now also _is_read
. For example:
{
"items": [
{
"type": "entry",
"url": "http://example.com/100",
...
"_id": "41003",
"_is_read": false
]
}
These new _id
values are meant to be opaque to clients, and must always be a string. Some servers will likely use integer database IDs, but other servers may use other string identifiers for entries depending on the implementation.
Retrieving the list of channels now also includes the number of unread entries in the channel:
{
"channels": [
{
"uid": "notifications",
"name": "Notifications",
"unread": 0
},
{
"uid": "YPGiUrZjNM36LNdpFy7eSzJE7o2aK82z",
"name": "IndieWeb",
"unread": 7
}
]
}
To mark an individual entry as read:
action=timeline
channel=example
method=mark_read
entry=1234
To mark multiple entires as read:
action=timeline
channel=example
method=mark_read
entry[]=1234
entry[]=5678
Both of the above also work with method=mark_unread
.
To mark an entry read as well as everything before it:
action=timeline
channel=example
method=mark_read
last_read_entry=1234
This is to address the use case of streams, where you really only care about knowing where in the stream you've scrolled to and whether there are any new entries since then.
This is mostly inspired by the Feedly Markers API Mark one or more articles as read and Mark a feed as read
The unread
property has been documented in the spec, and implemented in Aperture.
I am not sure the updated
property is useful, so I'm leaving it out for now. I'm going to close this issue as most of the discussion is taking place in #4.
With the work in tracking read state, I've started implementing these additional properties by prefixing them with _
. I felt like that was the least obtrusive way to include them while also making it obvious they are not part of the post vocabulary.
Additional brainstorming around other per-item data should be discussed in new issues.
Not that it has to be implemented right now, but I do want to make a case for the āupdatedā field of a channel. In order to reduce āhigh noise signalā, for most of my channels, Iāll want the channelās āunread indicatorā to disappear when I reach the top of the timeline (even if things are unread). When a channel is updated (receives new posts), I would want to be able to re-enable the unread indicator. Essentially saying āthere are new posts hereā rather than saying āthere are unread posts hereā. In fact now that I say it, I might make the indicator a different color as well. That said, the purpose of such a channel is, I want to be able to know what I have and havenāt read, while only being prompted to open the channel if there are new posts. The ānew postsā indicator essentially upping the priority of time looking at that channel than one without new posts. That said, when I have more time, to be able to go back to an existing channel and still know what I havenāt read (which is why this canāt just use the ālast_read_entryā, even though that is a useful method).
(Originally published at: https://eddiehinkle.com/2018/02/12/7/reply/)
Not that it has to be implemented right now, but I do want to make a case for the āupdatedā field of a channel. In order to reduce āhigh noise signalā, for most of my channels, Iāll want the channelās āunread indicatorā to disappear when I reach the top of the timeline (even if things are unread). When a channel is updated (receives new posts), I would want to be able to re-enable the unread indicator. Essentially saying āthere are new posts hereā rather than saying āthere are unread posts hereā. In fact now that I say it, I might make the indicator a different color as well. That said, the purpose of such a channel is, I want to be able to know what I have and havenāt read, while only being prompted to open the channel if there are new posts. The ānew postsā indicator essentially upping the priority of time looking at that channel than one without new posts. That said, when I have more time, to be able to go back to an existing channel and still know what I havenāt read (which is why this canāt just use the ālast_read_entryā, even though that is a useful method).
(Originally published at: https://eddiehinkle.com/2018/02/12/7/reply/)