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
