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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
