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
