[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Actually following on from this, I see @screenName/listName automatically links to the list on the site, so surely we have to be able to call the API using listNames too unless there is a reverse lookup API to convert list id to slug? On Oct 30, 11:31 pm, Rich rhyl...@gmail.com wrote: Well we be able to use slug or will we HAVE to use list id? At the moment I'm using the slug in my API calls On Oct 30, 5:53 pm, LeeS - @semel lse...@gmail.com wrote: Does calling the status timeline for a list count against rate limit? What I'm thinking of is doing an Ajax widget that auto updates with new tweets from a list every few seconds, similar to how many people use the Search API to do this by hashtag. If the status API request is rate limited this would obviously not work.
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
It appears that user/lists.xml only shows lists that are created by the user and not those that they follow. Any change coming to that or am I missing a way to see all lists that a user follows? Thanks, Jeremy On Oct 28, 3:00 pm, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
The update says all requests that produce a list *of lists* will have a cursor option. What about lists of members following/followed on/by a list? If I want to download the list of people following a list, members.xml currently gives only 20 users. Is there a way to ask for more, or to get the next page?
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Does calling the status timeline for a list count against rate limit? What I'm thinking of is doing an Ajax widget that auto updates with new tweets from a list every few seconds, similar to how many people use the Search API to do this by hashtag. If the status API request is rate limited this would obviously not work.
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Well we be able to use slug or will we HAVE to use list id? At the moment I'm using the slug in my API calls On Oct 30, 5:53 pm, LeeS - @semel lse...@gmail.com wrote: Does calling the status timeline for a list count against rate limit? What I'm thinking of is doing an Ajax widget that auto updates with new tweets from a list every few seconds, similar to how many people use the Search API to do this by hashtag. If the status API request is rate limited this would obviously not work.
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Marcel, Great changes. A couple of questions: - How long can a list description be? - A title can only be 15 chars - will that remain unchanged? - Will there be a little overlap where memberships and subscribers will still work while people migrate to followers/following? It would be awesome if there was a way to retrieve all member ids and a separate call for subscriber ids - cursored if necessary. Also, filed an edge case bug around list error messages a couple of days ago. http://code.google.com/p/twitter-api/issues/detail?id=1145sort=-openedcolspec=ID%20Stars%20Type%20Status%20Priority%20Owner%20Summary%20Opened%20Modified%20Component Cheers, Tim. On Oct 29, 9:00 am, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Answers inline: On Wed, Oct 28, 2009 at 1:14 PM, Tim Haines tmhai...@gmail.com wrote: Marcel, Great changes. A couple of questions: - How long can a list description be? 160 :-) - A title can only be 15 chars - will that remain unchanged? Unchanged. - Will there be a little overlap where memberships and subscribers will still work while people migrate to followers/following? Yeah. There will be overlap for some period of time for those who might need to transition. It would be awesome if there was a way to retrieve all member ids and a separate call for subscriber ids - cursored if necessary. Right, I'll add that to the list of things to consider :-) Also, filed an edge case bug around list error messages a couple of days ago. http://code.google.com/p/twitter-api/issues/detail?id=1145sort=-openedcolspec=ID%20Stars%20Type%20Status%20Priority%20Owner%20Summary%20Opened%20Modified%20Component Thanks. Cheers, Tim. On Oct 29, 9:00 am, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
+1 to this Any news on when the rest of us devs can get access to this to work on our apps? On Oct 28, 8:11 pm, Jesse Stay jesses...@gmail.com wrote: Maybe a little more appropriate to post this to a private list (no pun intended) for beta users? I admit I feel a little jealous every time I see one of these updates, unless there's some way to get into the beta. Thanks, Jesse On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Real soon now. We appreciate everyone's patience while we gradually ramp up traffic to lists to ensure we've got all our ducks in a row. On Wed, Oct 28, 2009 at 2:53 PM, Rich rhyl...@gmail.com wrote: +1 to this Any news on when the rest of us devs can get access to this to work on our apps? On Oct 28, 8:11 pm, Jesse Stay jesses...@gmail.com wrote: Maybe a little more appropriate to post this to a private list (no pun intended) for beta users? I admit I feel a little jealous every time I see one of these updates, unless there's some way to get into the beta. Thanks, Jesse On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
How does one keep a list up to date for a client without the concept of since_id, like we have for the timeline methods? I look at a lists as just a different timeline (granted one filtered to specific users), but that is how I would expect to view them in a client. From my understanding of cursors, on each request we have to start at -1 (to start paging) and page until we find an id that we already have locally. While this will work, it has a high probability of always over requesting data.. So if I have a list with two people in it, and they only tweet once a week, when I poll for updates of this list (say every 30min) the data is going to be the same most of the time(last 100 messages that these two people post). This seems like a waste of bandwidth for Twitter and us.. Some may argue that bandwidth is cheap, but it really is not on mobile devices. Some carriers charge per kb, but even on unlimited plans every byte transferred translates to additional battery drain.. Is there some concept of the cursor that I am not understanding that will allow us to also filter based on something like since_id? So we want to get messages newer than we already have and notify the user that the list has something new to display. Thanks to anyone who can clarify if I am misunderstanding something. --Naveen On Oct 28, 6:14 pm, Marcel Molina mar...@twitter.com wrote: Real soon now. We appreciate everyone's patience while we gradually ramp up traffic to lists to ensure we've got all our ducks in a row. On Wed, Oct 28, 2009 at 2:53 PM, Rich rhyl...@gmail.com wrote: +1 to this Any news on when the rest of us devs can get access to this to work on our apps? On Oct 28, 8:11 pm, Jesse Stay jesses...@gmail.com wrote: Maybe a little more appropriate to post this to a private list (no pun intended) for beta users? I admit I feel a little jealous every time I see one of these updates, unless there's some way to get into the beta. Thanks, Jesse On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
The cursors are for lists of lists and lists of users followed by/following lists. The statuses timeline for a given list takes all the same options you'd expect to manage status timelines. On Wed, Oct 28, 2009 at 5:43 PM, Naveen knig...@gmail.com wrote: How does one keep a list up to date for a client without the concept of since_id, like we have for the timeline methods? I look at a lists as just a different timeline (granted one filtered to specific users), but that is how I would expect to view them in a client. From my understanding of cursors, on each request we have to start at -1 (to start paging) and page until we find an id that we already have locally. While this will work, it has a high probability of always over requesting data.. So if I have a list with two people in it, and they only tweet once a week, when I poll for updates of this list (say every 30min) the data is going to be the same most of the time(last 100 messages that these two people post). This seems like a waste of bandwidth for Twitter and us.. Some may argue that bandwidth is cheap, but it really is not on mobile devices. Some carriers charge per kb, but even on unlimited plans every byte transferred translates to additional battery drain.. Is there some concept of the cursor that I am not understanding that will allow us to also filter based on something like since_id? So we want to get messages newer than we already have and notify the user that the list has something new to display. Thanks to anyone who can clarify if I am misunderstanding something. --Naveen On Oct 28, 6:14 pm, Marcel Molina mar...@twitter.com wrote: Real soon now. We appreciate everyone's patience while we gradually ramp up traffic to lists to ensure we've got all our ducks in a row. On Wed, Oct 28, 2009 at 2:53 PM, Rich rhyl...@gmail.com wrote: +1 to this Any news on when the rest of us devs can get access to this to work on our apps? On Oct 28, 8:11 pm, Jesse Stay jesses...@gmail.com wrote: Maybe a little more appropriate to post this to a private list (no pun intended) for beta users? I admit I feel a little jealous every time I see one of these updates, unless there's some way to get into the beta. Thanks, Jesse On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Updates to the List API (list descriptions, cursoring lists of lists, finding by list id rather than slug more consistent names)
Thanks for the quick response. I guess I was confused. On Oct 28, 2009, at 8:53 PM, Marcel Molina wrote: The cursors are for lists of lists and lists of users followed by/following lists. The statuses timeline for a given list takes all the same options you'd expect to manage status timelines. On Wed, Oct 28, 2009 at 5:43 PM, Naveen knig...@gmail.com wrote: How does one keep a list up to date for a client without the concept of since_id, like we have for the timeline methods? I look at a lists as just a different timeline (granted one filtered to specific users), but that is how I would expect to view them in a client. From my understanding of cursors, on each request we have to start at -1 (to start paging) and page until we find an id that we already have locally. While this will work, it has a high probability of always over requesting data.. So if I have a list with two people in it, and they only tweet once a week, when I poll for updates of this list (say every 30min) the data is going to be the same most of the time(last 100 messages that these two people post). This seems like a waste of bandwidth for Twitter and us.. Some may argue that bandwidth is cheap, but it really is not on mobile devices. Some carriers charge per kb, but even on unlimited plans every byte transferred translates to additional battery drain.. Is there some concept of the cursor that I am not understanding that will allow us to also filter based on something like since_id? So we want to get messages newer than we already have and notify the user that the list has something new to display. Thanks to anyone who can clarify if I am misunderstanding something. --Naveen On Oct 28, 6:14 pm, Marcel Molina mar...@twitter.com wrote: Real soon now. We appreciate everyone's patience while we gradually ramp up traffic to lists to ensure we've got all our ducks in a row. On Wed, Oct 28, 2009 at 2:53 PM, Rich rhyl...@gmail.com wrote: +1 to this Any news on when the rest of us devs can get access to this to work on our apps? On Oct 28, 8:11 pm, Jesse Stay jesses...@gmail.com wrote: Maybe a little more appropriate to post this to a private list (no pun intended) for beta users? I admit I feel a little jealous every time I see one of these updates, unless there's some way to get into the beta. Thanks, Jesse On Wed, Oct 28, 2009 at 2:00 PM, Marcel Molina mar...@twitter.com wrote: Two additions and two changes to the List API will be deployed in the next few days: * List descriptions We're adding a description to every list. You'll be able to specify a description when you create or update a list and the description will be included in the payload. * Cursoring through lists of lists All resources that return a list of lists will include next and previous cursors and will accept a :cursor parameter. * Finding by list id rather than slug When you change the name of a list, the slug will be updated to reflect that change. That means using the slug in the url for resources to operate on lists requires the onerous task of validating that the slug for the list you are about to do something with hasn't been updated since the last time you stored its slug. What a nightmare :-) Every list also has an id. This value won't change. We'll be changing the API to replace all instances of a list slug in urls to be list ids instead. * Consistent names The terminology we've used thus far for people you follow with a list is members. The terminology for people who are following a list is subscribers. We're going to mirror the terminology used for users and change it to followers and following respectively. So: /:user/lists/:list_id/memberships becomes /:user/lists/:list_id/ followers /:user/lists/:list_id/subscribers becomes /:user/lists/:list_id/ following As we deploy these changes we'll send out a heads up on the dev list and @twitterapi. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
