| Issue 171: | Feature Request: Need a way for clients to exchange information | |
| 9 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
There is currently no way for Twitter clients to exchange information. The primary need for this functionality is between desktop and mobile clients. Consider this scenario: 1) A user is reading tweets using their desktop client in an office. They have a read up to a certain position in their timeline. 2) The user shutsdown their desktop machine and leaves their office. 3) While waiting for a bus, the user opens a mobile client and starts to read tweets. At this point, the mobile client does not know where the user was in the timeline. An API to create an arbitrary hash of values would allow the client in step #1 to record information and the client in step #3 to read it. |
||||||||||
,
Dec 01, 2008
At the very least, the option for applications to update a last_read counter per-user would suffice.
Status: Accepted
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low |
|||||||||||
,
Dec 01, 2008
(No comment was entered for this change.)
Owner: alexfpayne
|
|||||||||||
,
Dec 01, 2008
Probably better to call it last_id since it's not necessarily something that's tied to "reading". Some users want it to represent the highest ID from the last batch the client has pulled down, others will want it to represent the ID of the tweet that's currently selected. |
|||||||||||
,
Dec 02, 2008
(No comment was entered for this change.)
Labels: Milestone-V2
|
|||||||||||
,
Dec 02, 2008
If something like this is to be added it must have fixed semantics or two arbitrary clients will not be able to use it to communicate effectively. Overloading the meaning of a field in an API is not a good move. Hence names like last_read_id or last_read_date are far better, and more developer-friendly. That said, if Twitter will be storing this value then realistically the clients need never be exposed to it - there could be a 'catch up' extension to the timeline API methods to achieve the same goal. This would avoid the risk of broken clients updating it wrongly and save a small amount of bandwidth in the process. |
|||||||||||
,
Apr 21, 2009
This issue has been recoreded in the future roadmap: http://apiwiki.twitter.com/V2-Roadmap
Status: Moved
|
|||||||||||
,
Apr 21, 2009
Marking "Invalid" so these issues don't clutter the main view of issues. All are tracked on http://apiwiki.twitter.com/V2-Roadmap
Status: Invalid
|
|||||||||||
,
May 27, 2009
Given the different ways you can browse your follower's timeline, a simple last_read_id would not necessarily bring a lot of value. Would rather see an API that would allow to synchronize (in the cloud) all the tweets read for a single user. |
|||||||||||
 Sign in to add a comment
|
|||||||||||
