Re: Request for testing data from Twitter (Request / suggestion for offical WADL and WSDL)
Lukas,
Thank you for the pointer to and the effort put into creating the WADL
and WSDL.
I'm new to the group, and to Twitter for that matter, but I'm somewhat
surprised that there aren't an official WADL and WSDL for the service.
Or any other complete specification that I can find. Am I missing
something?
I would strongly suggest that official WADL and WSDL be developed and
maintained.
Comments appreciated in advance.
Jim Renkel
On Sep 29, 1:01 pm, Lukas Jungmann [EMAIL PROTECTED] wrote:
Hi Alex,
On Mon, Sep 29, 2008 at 7:36 PM, Alex Payne [EMAIL PROTECTED] wrote:
This is a great idea, and something I've been planning on doing since
the API became my full-time job several weeks ago. Thanks for the
suggetion, DeWitt!
in case you'll (or anyone else) find WADL for the API and/orXMLschemafor API
responses useful for the community, you can find them
at:http://tinyurl.com/4sh8e2
I'm not saying it's perfect but can be a good start...
regards,
--lj
On Sun, Sep 28, 2008 at 12:07 PM, DeWitt Clinton [EMAIL PROTECTED] wrote:
Hi Alex, and all,
I was upgrading the java-twitter and python-twitter libraries recently,
partly in anticipation of the upcoming changes to the JSON format, and I
realized something that might be of great benefit to the community of
Twitter api library authors.
Part of my testing strategy is to collect real-world results and run them
through each library as a way of smoke testing each call. To date, I've
been collecting sample data myself by running queries using my own test
accounts.
However, if would be even better if Twitter published a collection of
canonical test datasets corresponding to the various API calls. That way
every library author could use the same sample data to test against, and we
could be sure that our code matched the Twitter API's expectations.
For example, what if Twitter maintained a public read-only SVN repository
that contained sample data files like the following:
public_timeline.json:
GEThttp://twitter.com/statuses/public_timeline.json
[{user:{followers_count:66, ...
public_timeline.atom:
GEThttp://twitter.com/statuses/public_timeline.atom
?xmlversion=1.0 encoding=UTF-8?
feedxml:lang=en-US xmlns=http://www.w3.org/2005/Atom;
titleTwitter public timeline/title
idtag:twitter.com,2007:Status/id
link href=http://twitter.com/public_timeline; type=text/html
rel=alternate/
updated2008-09-28T18:48:13+00:00/updated
subtitleTwitter updates from everyone!/subtitle
entry
...
user_timeline.xml:
GET testuser:[EMAIL PROTECTED]://twitter.com/statuses/user_timeline.xml
?xmlversion=1.0 encoding=UTF-8?
statuses type=array
status
created_atSun Sep 28 17:09:33 + 2008/created_at
id938260897/id
textAs of midnight last night, I've been getting a 3G signal on my
T-Mobile device in San Francisco, CA./text
sourceweb/source
truncatedfalse/truncated
...
And so on and so forth for each permutation of the various API calls and
formats. They should be versioned (perhaps using SVN tags) so we can test
against past and upcoming API changes as well. This is especially valuable
for non-idempotent state-changing POST calls (which are the majority),
where
it is difficult to maintain a stable set of test data between versions.
Yes, it would be a little bit of work on the Twitter side, but it could
likely be automated. Moreover, this would have the advantage of being
official data for us to test against, which like a pretty reasonable
request
if the community is going to continue to maintain and develop libraries
that
are expect to work as the Twitter API is updated and potentially introduces
non-backward compatible changes.
What do you think?
Cheers,
-DeWitt
--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x
Re: Opinions wanted: a more RESTful way to update your status
I too like Joel's idea. Jim Renkel On Oct 14, 2:58 pm, Vinuth Madinur [EMAIL PROTECTED] wrote: +1 to what Joel said. On Wed, Oct 15, 2008 at 12:37 AM, jstrellner [EMAIL PROTECTED] wrote: Personally I've always liked URI's that can be broken into name/value pairs. In this case, I would like to see: http://api.twitter.com/v/1.0/status/bob.xml What it is basically saying is: - Version: 1.0 - Status for Bob in XML If we are POSTing to it, you know (progamatically) that we are trying to update that user (and that we should be authenticated as that user). If we are GETing it, you know that we want to see all of that users status updates (and authenticated as one of their friends if they are protected). Basically, I guess I am proposing the merging of statuses and user_timeline into just status. If you get rid of the generic URLs, then you can easily make sure that they are posting to the right account. If they are currently authenticated as sally, but they are trying to post to http://api.twitter.com/v/1.0/status/bob.xml, you know that something is wrong since they should be posting tohttp://api.twitter.com/v/1.0/status/sally.xml -Joel On Oct 13, 5:11 pm, Alex Payne [EMAIL PROTECTED] wrote: I'm sitting down with @mzsanford this week to spec out what we're calling the API Service internally, the next version of the Twitter API. We're going to have a number of questions that we want your feedback on, and this is the first. Currently, the URL to which you POST to update a user's status is this: http://twitter.com/statuses/update.format This breaks RESTful conventions and is generally a bit ugly. We're considering one of the following, either: POSThttp://api.twitter.com/1/statuses.xml ... or: POSThttp://api.twitter.com/1/users/bob/statuses.xml The difference is all in RESTful semantics. In the first case, you're POSTing a new status to the universal collection of statuses. In the second case, you're POSTing a new status to user bob's collection of statuses. Which do you all prefer and why? Alternatives welcome. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: Problem with replying to messages
OK, the replies and this new post are now visible some 15 minutes later. I guess I just wasn't patient enough. :-) Thanks, Jim Renkel On Oct 14, 7:09 pm, Ed Finkler [EMAIL PROTECTED] wrote: Posts from new users are moderated. Spam is just too bad on Google Groups now (I've seen it on several others I am on or maintain). -- Ed Finklerhttp://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Tue, Oct 14, 2008 at 8:05 PM, jim.renkel [EMAIL PROTECTED] wrote: I've tried replying to several messages in the twitter API discussion threads, get a reply that the post was successful, but the message doesn't show up. I've done this many other times in other Google groups with no problem. Any ideas what I might be doing wrong here? Anybody else seeing this? Thanks in advance, Jim Renkel
[twitter-dev] Re: Reserved usernames
Richard, I think the problem you're trying to solve here is: given a URL of the form http://twitter.com/xxx, is xxx a valid twitter username? (At least that's a problem that I'm trying to solve for an application I'm developing.). A static list of such xxx's, although interesting, can't be developed given the current naming convention for pages in the twitter web site, because the xxx's that aren't valid usernames are all pages in the website. As the website expands, as it has recently, the list will grow. So, what to do? I have two suggestions, neither of which I really like, but that's often the case when ya have to consider backward compatibility in crafting solutions: 1) Add a method to the API that returns a list of xxx's that are not valid user names but are twitter website pages; an application would call this whenever it needed the list. Better than having a static list in applications, which would require redistribution of the applications whenever the list changes, but I worry about the list being kept accurate (Unfortunately, I have had bad experiences with these kinds of lists.). 2) Twitter changes the structure of their site so that URLs for valid users are something like http://twitter.com/user/xxx, with the guarantee that a URL of that form would never be used for anything but a valid user. (I don't see twitter making a change like this, but I could be wrong. And there are backward compatibility problems with URLs that are already archived or cached someplace.) Comments expected and welcome. Jim Renkel On Mar 15, 8:36 am, richardhenry richardhe...@me.com wrote: Could anyone help me complete a list ofreservedTwitter usernames? I'm talking about the usernames that cannot be registered because they're used in Twitter URLs. @home @account @admin @help @login @signup @about @replies @direct_messages @favorites @public_timeline @invitations @downloads @jobs @terms @privacy @sessions Is this everything, or have I missed anything? Richard
[twitter-dev] Re: Purposed method: friendships/show
It seems from the examples, but not explicitly stated anywhere, that
the values of the following and followed_by items are booleans,
implying that a user either is or is not following another user.
While at first blush that seems true, I think in reality the situation
is a little more complicated, especially if you consider protected
users.
I would propose that these items be enumerations, with the following
values and meanings:
- yes: user A, say, is following user B;
- no: user A is not following user B, has not requested the
relationship, and is not blocked from doing so;
- pending: user A has requested to follow (protected) user B, but B
has not yet accepted, rejected, or blocked the request; and
- blocked: user A requested to follow (protected) user B, but B
blocked the request.
What I'm looking for here is parity, if you will, between the data and
facilities that are available to the twitter.com web site and to API
users. This is one place where there was not parity, and we have the
opportunity to now get it.
Comments expected, welcome, and appreciated.
Jim Renkel
On Jun 9, 1:13 pm, Damon Clinkscales sca...@pobox.com wrote:
If you're going to redefine the way that follow information is
returned, I believe that it should include the effect of protected
accounts on both sides of the follow equation.
Thanks,
-damon
--http://twitter.com/damon
On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molinamar...@twitter.com wrote:
Thanks for the suggestion Chad.
What do others think of
{relationship: {
source: {
id: 123,
screen_name: bob,
notifications: false },
target: {
id: 456,
screen_name: jack,
notifications: null },
source_follows_target: true,
source_followed_by_target: false
}
}
versus
{relationship: {
source: {
id: 123,
screen_name: bob,
following: true,
followed_by: false,
notifications_enabled: false },
target: {
id: 456,
screen_name: jack,
following: false,
followed_by: true,
notifications_enabled: null }
}
}
[twitter-dev] Re: Purposed method: friendships/show
In thinking this through a little more and how this would fit into my
applications, I have another suggestion to propose.
Currently, if an application requests the followers of user B, on
behalf of user A (i.e., the request is authenticated with user A's
credentials), it gets back the list of B's followers, their latest
status update, plus (partial) indications of the relationship between
each of B's followers and user A. The application can use that
information to enable user A sending DMs to the follower if that
follower of B is also following A, to enable user A to request to
follow the follower of B if they are not already doing so, or remove
the follow if they are, etc., etc., etc.
If that relationship information is not included in the response to
the request for the followers of B, but must be requested separately,
as is being proposed, the real problem that I see is that, as
proposed, if I get back 50 followers of B in the response to the
request for B's followers, I now have to make 50 relationship requests
to get the same information that was included before, albeit
inaccurately. This has big implications for latency, server overhead,
rate limits, etc., etc., etc.
What I propose is that a request for relationship information can
include a list of targets, and the response would include the
relationship information for each target in the list vis-a-vis the
source user.
Of course, now ya run into complications concerning the validity of
target users: I would hope that ya would not reject the whole request
just because one or more target users were invalid, but that ya would
selectively indicate the invalidity, and return the requested
information for valid targets.
I don't know what the impact of adopting this proposal would be on the
API server side, but the impact of NOT adopting this suggestion is
potentially huge on both the client and server.
And, on a different tangent, is there any impact in this on the
favorited indication that appears as part of a status update's
information in some API responses? Will we be expected to have to make
separate API requests to get that information?
Again, comments expected, welcome, and appreciated.
Jim Renkel
On Jun 9, 7:51 pm, Chad Etzel jazzyc...@gmail.com wrote:
If adding the other states (pending, blocked, etc) then I would agree
with the redundancy by having all attributes present in both
source and target objects. These relationships are not
necessarily symmetric, so it makes sense to have them in each object
since they would not necessarily be redundant.
-Chad
On Tue, Jun 9, 2009 at 8:22 PM, Marcel Molina mar...@twitter.com wrote:
Good point about pending requests for protected accounts and the opportunity
to get parity.
My inclination is rather than overloading following and followed_by that we
potentially introduce a 'pending' attribute that is either true or empty.
Similarly we could add a 'blocked'/'blocked_by'.
These additional attributes sway me toward going with the
representation that (redundantly) specifies the values of each attribute with the source and target sections as encoding this information in 'source_has_a_pending_request_for_target' and 'target_has_a_pending_request_for_source', etc start to get somewhat unwieldy.
On Tue, Jun 9, 2009 at 4:29 PM, jim.renkel james.ren...@gmail.com wrote:
It seems from the examples, but not explicitly stated anywhere, that
the values of the following and followed_by items are booleans,
implying that a user either is or is not following another user.
While at first blush that seems true, I think in reality the situation
is a little more complicated, especially if you consider protected
users.
I would propose that these items be enumerations, with the following
values and meanings:
- yes: user A, say, is following user B;
- no: user A is not following user B, has not requested the
relationship, and is not blocked from doing so;
- pending: user A has requested to follow (protected) user B, but B
has not yet accepted, rejected, or blocked the request; and
- blocked: user A requested to follow (protected) user B, but B
blocked the request.
What I'm looking for here is parity, if you will, between the data and
facilities that are available to the twitter.com web site and to API
users. This is one place where there was not parity, and we have the
opportunity to now get it.
Comments expected, welcome, and appreciated.
Jim Renkel
On Jun 9, 1:13 pm, Damon Clinkscales sca...@pobox.com wrote:
If you're going to redefine the way that follow information is
returned, I believe that it should include the effect of protected
accounts on both sides of the follow equation.
Thanks,
-damon
--http://twitter.com/damon
On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molinamar...@twitter.com
wrote:
Thanks for the suggestion Chad.
What do others think of
{relationship: {
source: {
id: 123
[twitter-dev] Re: Updating the APIs authentication limiting policy
My concern with this proposal is that it opens up denials of service, not to twitter.com, but to associated sites such as twitpic, or my site twxlate, among others For example, Lance Armstrong is a heavy user of twitpic. It is very easy for anyone to find Lance's twitter ID (@lancearmstrong), view his status updates, and see that he is a frequent user of twitpic. Now, someone that is unhappy with Lance, say one of George Hincapie's ardent fans that really believes that Lance was a significant contributor to George not winning the maillot jeune last Sunday, could go to twitpic, fail to login as Lance the requisite number of times, and deny Lance access to twitpic. Not only celebrities would or could be subject to such denials of service. I notice that @dougw occasionally uses twitpic! :-) One solution to this problem is to add to each twitter account another private ID. By default this private ID would be equal to the existing (public) ID (If not equal to the account's public ID, it would have to be unique among all twitter IDs, both public and private.). The public ID would be used just as the existing twitter ID is now: others would use it to follow, mention, DM, etc., the user. But the user MUST use their private ID for authenticated requests through the API, and CAN also use it for non-authenticated requests. In either case, twitter would treat a request from a private ID as if it came from the corresponding public ID. Blocking the public ID because of excessive authentication failures would NOT block the associated private ID unless they were equal. Changing your public ID would also change your private ID if the two were the same before the change, i.e., they would remain the same after the change. It may seem onerous to require all users to also have a private ID, but since it defaults to be the same as their public ID, only those concerned about their service being denied would change it and subsequently use it instead of their public ID to access associated sites such as twitpic or twxlate. In fact, I think this change, though potentially large on the twitter side, could be implemented without any changes to users or associated sites, with one small, obscure exception: now, if I attempt to create a new twitter account or change the ID of an existing account, and find that the ID I want is in use, I can view that account; if this were implemented and I attempted to use a private ID that was not the same as its associated public ID, I could not view the account using the denied ID. Comments expected and welcome. Jim Renkel On Jul 21, 6:00 pm, Doug Williams d...@twitter.com wrote: Devs --A change shipped last week that limited the number of times a user could access the account/verify_credentials method [1] in a given hour. This change proved hasty and short-sighted as pointed out by the subsequent discussion [2]. We apologize to any developer that was adversely affected. Given the problems, we want to fix this in a public and transparent manner. Like most web services, we limit the number of attempts users can make to login to their accounts on Twitter.com to prevent brute force dictionary attacks. This same security is not extended to the platform and leaves accounts vulnerable to the same method of attack through the API. The change we shipped to limit user accounts to 15 calls an hour to the account/verify_credentials method [1] was intended to mitigate this risk. It was thought to limit the number of tests a potential attack could run in the hour, even in a distributed fashion. However, we only protected a single resource which still leaves all other authenticated methods exposed as a vector of attack (limited only by the API rate limit). Our thinking is now that we will limit the total number of unsuccessful attempts to access authenticated resources to 15 an hour per user per IP address. If a single IP address makes 15 attempts to access a protected resource unsuccessfully for a given user (as indicated by an HTTP 401), then the user will be locked out of authenticated resources from that IP address for 1 hour. This scheme has all of the positive effects that we need, however we want to make sure that we have thought through all of the potential problems on the developer's side before we proceed with this change. Please contribute to the subsequent discussion if you have an opinion or concern. Once we come to an agreement, we will update with details and a timeline for shipping this update. 1.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0ve... 2.http://groups.google.com/group/twitter-development-talk/browse_thread... Regards, Doug
[twitter-dev] Re: Updating the APIs authentication limiting policy
Owkaye, Thanks for the comment and suggestion. The problem with implementing this locally at associated web sites rather than centrally at twitter is that: - each site would have to implement it separately; and - users would have to sign up and create a private ID at each site they use. That results in much confusion and duplication of effort both for web site developers and users. It would be be much less confusing and require much less total effort if it were done centrally. That said and given twitter's priorities and available resources, I don't expect them to implement this scheme or anything like it. And, at this time, we don't even know if this is a real issue or just a red-herring. I raised it because I saw it as a theoretical problem with the proposal, not because anyone that I know has experienced this problem. Does anybody see this as a real or potential problem, or should we just let the issue fade away? Comments expected and welcome. Jim On Jul 22, 3:28 pm, owkaye owk...@gmail.com wrote: One solution to this problem is to add to each twitter account another private ID. Jim, Wouldn't it make more sense to implement this private id thing on your own server? My thought here is that your service should maintain its own database of users, and issue a unique private id for each of these users. Then when the visitor tries to login, your code can check to see if the private id the visitor has entered is in your own database. If so the person is allowed to login, and if not they get an error. Would this work to solve the problem of am I missing something here? Owkaye
[twitter-dev] Re: Twitter Update, 8/10 noon PST
Yup, when you do back-offs, ya can't do them deterministically, ya gotta do them for a random amount, generally uniformly distributed between some upper and lower bounds. It's the bounds that increase geometrically or exponentially, up to some limit, but the each back-off should be random between the bounds. If the back-offs are not randomized, its leads to synchronicity, as you noted. BTW, all standardized back-offs of which I am aware specify randomized back-off. Jim Renkel On Aug 10, 7:54 pm, Michael Chang thenewm...@gmail.com wrote: On Mon, Aug 10, 2009 at 3:36 PM, Dewald Pretorius dpr...@gmail.com wrote: On Aug 10, 3:57 pm, Ryan Sarver rsar...@twitter.com wrote: As such the system has more general strain on it and thus will produce some more 502/503 errors. If you see them, you should do a geometric back off instead of just sending a new request. Ryan, What starting value and what common ratio of a geometric back off would you recommend? One issue with back off (geometric or otherwise) is that if everyone uses the same values; it won't work. Think about it -- let's say 10 000 users all access the system simultaneously and all of them get 502/503 errors. Then let's say they all wait five seconds before retrying. Once those five seconds are up; they will all simultaneously accesss the site again, and likely again get the same 502/503 errors. This causes them all to back off again, say, for 25 seconds. Then they will all again contact the server again, at the same time, and so on and so forth until either they all give up, or until the end of time, whichever comes first. (Yes, this is a simplified example, but it should get the point across. In practice, at least a few users might get through every time, and eventually, yes, everyone would get served if they are patient enough. But if everyone uses different back-off values, then the traffic becomes somewhat more even, and thus the servers can cope with the load more easily.) -- Thanks, Michael Chang I may not be able to open heavily-formatted Word, Powerpoint, or Excel documents. Send at your own risk.
[twitter-dev] Re: Rate limit question (again/followup) 20k user or ip?
Hmmm! We seem to have conflicting evidence here! I just (again) verified that twxlate.com is getting 20k requests per hour per user. How long ago was it that Alex and other API team members made the recommendation that you mentioned? Is it possible that twitter changed policy since then? Either way, I agree that we now need a very clear affirmation from twitter as to the policy. I sure hope I don't have to eat my words! :-) Jim On Aug 10, 9:08 pm, Dewald Pretorius dpr...@gmail.com wrote: On Aug 10, 11:02 pm, jim.renkel james.ren...@gmail.com wrote: My logic is now: Ifratelimiting is not peruser, then all users of anIPaddress will share one pool of20krequests per hour. If a site has a 1,000 users at one time, then eachuserwill get an average of 20 requests per hour. This is clearly not enough to do much useful. Jim, That is why Alex and other API team members have recommended in the past that you get and use additional white-listedIPaddresses, when 20,000 requests per hour perIPaddress is not sufficient to service youruserbase. At TweetLater I employ several white-listedIPaddresses to cover the needs of my users. Dewald
[twitter-dev] Re: Twitter Update, 8/10 noon PST
Geometric backoffs are more generally know as exponential backoffs. If ya google that, ya get a couple of useful and interesting things: http://en.wikipedia.org/wiki/Exponential_backoff http://en.wikipedia.org/wiki/Truncated_binary_exponential_backoff http://dthain.blogspot.com/2009/02/exponential-backoff-in-distributed.html etc. Hope this helps. Jim On Aug 11, 12:01 am, hansamann sven.hai...@googlemail.com wrote: Can someone post a link to some online resources explaining more aboutgeometricback-offs? Did a search, did not find a whole lot. Thx Sven On Aug 10, 7:18 pm, jim.renkel james.ren...@gmail.com wrote: Yup, when you doback-offs, ya can't do them deterministically, ya gotta do them for a random amount, generally uniformly distributed between some upper and lower bounds. It's the bounds that increase geometrically or exponentially, up to some limit, but the each back-off should be random between the bounds. If theback-offsare not randomized, its leads to synchronicity, as you noted. BTW, all standardizedback-offsof which I am aware specify randomized back-off. Jim Renkel On Aug 10, 7:54 pm, Michael Chang thenewm...@gmail.com wrote: On Mon, Aug 10, 2009 at 3:36 PM, Dewald Pretorius dpr...@gmail.com wrote: On Aug 10, 3:57 pm, Ryan Sarver rsar...@twitter.com wrote: As such the system has more general strain on it and thus will produce some more 502/503 errors. If you see them, you should do a geometric back off instead of just sending a new request. Ryan, What starting value and what common ratio of ageometricback off would you recommend? One issue with back off (geometricor otherwise) is that if everyone uses the same values; it won't work. Think about it -- let's say 10 000 users all access the system simultaneously and all of them get 502/503 errors. Then let's say they all wait five seconds before retrying. Once those five seconds are up; they will all simultaneously accesss the site again, and likely again get the same 502/503 errors. This causes them all to back off again, say, for 25 seconds. Then they will all again contact the server again, at the same time, and so on and so forth until either they all give up, or until the end of time, whichever comes first. (Yes, this is a simplified example, but it should get the point across. In practice, at least a few users might get through every time, and eventually, yes, everyone would get served if they are patient enough. But if everyone uses different back-off values, then the traffic becomes somewhat more even, and thus the servers can cope with the load more easily.) -- Thanks, Michael Chang I may not be able to open heavily-formatted Word, Powerpoint, or Excel documents. Send at your own risk.
[twitter-dev] Re: RateLimit Calculation
As I've pointed out in other posts to this group, and I will be the first to acknowledge that there are conflicting opinions and facts on this, it is my understanding and experience that for GET requests that require authorization the rate limit is per user per IP address: -If *EITHER* the user or the IP address or both are white-listed, then the rate limit is 20k requests per hour for that user using that IP address. - If *NEITHER* the user nor the IP address is white-listed, the the rate limit is 150 requests per hour, again for that user using that IP address. So, again as I understand it, either of your scenarios should work OK, and in neither case should you be black-holed. In scenario 1, you would have 10k users * 20k requests per hour for an aggregate rate limit of 200kk (i.e., 200 million) requests per hour. Even if you corner the market on twitter API usage, I can't imagine generating that many requests per hour! :-) In scenario 2, you would have 10k users * 150 requests per hour for an aggregate rate limit of a mere 1.5kk (i.e, 1.5 million) requests per hour. You probably can't corner the market with that limited capacity. Oh well, I guess you'll have to find another business model! :-) BTW, IMHO, I believe that what the twitter API spec is calling authenticated requests should be called authorized requests. Authentication is a prelude and prerequisite to authorization, and in delivering the requested service the API is authorizing you to receive the service for the authenticated user. If the API were just authenticating the user, it would return a simple, binary Yes, the user has been authenticated to our satisfaction or No, the user has not been authenticated to our satisfaction answer to a request for authentication. Comments expected and welcome. Jim Renkel On Aug 11, 6:51 pm, shiplu shiplu@gmail.com wrote: On Wed, Aug 12, 2009 at 6:41 AM, Julio Biasonjulio.bia...@gmail.com wrote: On Wed, Aug 12, 2009 at 7:01 AM, shiplushiplu@gmail.com wrote: Oops! Basic Mistake! But what about I am talking about GET requests. If you're doing a GET 3 times every hour, then it would be better not use a whitelisted IP. This way, the rate limit will count to each user, not the IP (considering that you're authenticating those users.) But there is a chance my IP will be blacklisted, isn't it? Also If I just cache every request, It will never hit the rate limit. -- A K M Mokaddimhttp://talk.cmyweb.nethttp://twitter.com/shiplu Stop Top Posting !! বাংলিশ লেখার চাইতে বাংলা লেখা অনেক ভাল Sent from Dhaka, Bangladesh
[twitter-dev] Re: FW: Twitter is Suing me!!!
I guess I should have pointed out that my tongue was firmly planted in my check when I wrote my previous post. My bad! :-( Dean: I don't mean to make light of your particular situation. Sometimes I just can't not point out absurdities, which the logic I presented clearly is. What I was trying to do, perhaps not too well, is point out that the API TOS may need to be revised to say that developers may use twitter's trademarks, but only in approved ways. BTW, twitter is trademarking tweet as well as twitter. You have been warned! :-) Jim On Aug 11, 10:50 pm, jim.renkel james.ren...@gmail.com wrote: An interesting implication is buried in all of this. FACT:http://apiwiki.twitter.com/Terms-of-Servicestates: Please give us a nod in your app, perhaps by including one of these stylish Powered by Twitter badges, which I read as If ya use the API you must acknowledge twitter. FACT: The letter from twitter's lawyers states: stop all use of ... the TWITTER mark, which I read as Ya can't use the word twitter in your application or on your website. IMPLICATION: No one can use the API !!! I guess we should all pack up and move on. Jim On Aug 11, 10:13 pm, Larry Wright larrywri...@gmail.com wrote: As others have pointed out, this isn't a lawsuit. That aside, Twitter announced some time ago that they were not comfortable with people using their name as part of the name of their product (http://blog.twitter.com/2009/07/may-tweets-be-with-you.html) , so it seems odd that you would be surprised by this. Regardless, you'll get little sympathy from me. Your application encourages many of the behaviors most twitter users find annoying. The Twitter ecosystem is frankly better off without it. Larry Wrighthttp://larrywright.me On Aug 11, 2009, at 9:48 PM, Dean Collins wrote: Any other developer being sued by Twitter today? If so give me a call – feel free to tweet outwww.MyTwitterButler.com/I ’m_Being_Sued to anyone you want – looking forward to the press having a field day with this. Regards, Dean Collins d...@mytwitterbutler.com +1-212-203-4357 New York +61-2-9016-5642 (Sydney in-dial). +44-20-3129-6001 (London in-dial).
[twitter-dev] Re: FW: Twitter is Suing me!!!
IANAL, but I don't think all is doom and gloom, or at least not as doomy and goomy as previous posts to this thread (Including one of mine, if it is not read as tongue-in-cheek, as intended) portray. Yes, if you have a trademark, you have to aggressively defend it or risk losing it. No, completely barring others from using it is not the only way to aggressively defend it. You can license it, subject to some terms and conditions, and aggressively police the licensing program. I know this because in a previous life I made modems. These modems included many significant innovations, which were protected by patents. Now, modems are like dancing: it takes two to twango (GDI! I've got o stop doing that! :-) ). And even though the company for which I worked had at one time an ~85% market share of dial-up modems, there was still that pesky ~15% from competitors that wanted to interoperate with ours. To do that, they had to include our innovations, and the companies that built them, our competitors, had to license the innovations. Each innovation had a catchy, trade-marked brand name, and along with licensing the innovations the other companies would license the brand name for use in their labeling, promotion, and advertising. In fact, the licensing terms and conditions *REQUIRED* them to do so, or risk having the license terminated. All fine and dandy, so far. But it addition to the other modem manufacturers, ISPs that purchased these modems, either from us or others, wanted to advertise that they provided service that included these innovations. Unlike licensing the technology, purchasing a product containing the technology did *NOT* grant you license to use the technology's trademarked brand name in your labeling, promotions, and advertising: they had to separately license the trademarked brand name. Now licensing is never free, it always involves compensation. (Why? Don't ask me, IANAL) But the compensation is not necessarily monetary, it may be a requirement to actually use the brand name to promote your service, thereby promoting the technology. I.e., if you actually run advertising (For your service) that includes the brand name upon which your service is built, then you have promoted the brand name and thereby compensated us for licensing the brand name to you; if you don't advertise, then you haven't compensated us, and we pull the license. All of this, of course, subject to terms and conditions contained in the license agreement. I know this is how it worked because periodically my engineering team would gets updates from the legal department on new licensees (I.e., people we could and should talk to) and terminated licensees (I.e., people we couldn't and shouldn't talk to). I know for a fact that in some cases licenses to use the trademarked brand names were terminated because their service and/or advertising violated the terms and conditions of the license (Most such cases involved providing or promoting illegal activities; for example, child pornography). How is all of this relevant to the case at hand? Twitter could (And I sincerely hope they do.) license the use of their trademarks to us, developers of products that interoperate with their services, subject to terms and conditions, with the only compensation being that ya have to actually use the trademarks to promote your product and thereby their service. If ya actually use the trademarks (And abide by the terms and conditions) your license stays in effect; ya don't use the trademarks (Or you violate the terms and condition) your license is terminated. Again, IANAL, but I don't see any reason that the licensing of the trademarks could not include their use in product and domain names. And maybe the licensing process is as simple as signing up for an OAuth consumer key, agreeing to the trademark licensing terms and conditions as part of the OAuth sign-up. Naw! That wouldn't work, it's too easy! :-) Comments expected and welcome, Jim Renkel On Aug 13, 2:19 pm, JDG ghil...@gmail.com wrote: did you really expect them to allow something that clearly violated their TOS to use the Twitter name? There are plenty of apps out there that add Real Value(TM) to Twitter's community. On Thu, Aug 13, 2009 at 13:05, Dale Merritt mogul...@gmail.com wrote: You're right, they could decide to grant you the right to use it. Good luck with that. Keep building up that brand then and cross your fingers. Sounds like a sound assumption. On Thu, Aug 13, 2009 at 11:43 AM, Nick Arnett nick.arn...@gmail.comwrote: On Thu, Aug 13, 2009 at 9:20 AM, Dale Merritt mogul...@gmail.comwrote: Don't waste your time. If you have Twitter in your domain name, you could be put out of business if you don't cease and desist. I've seen it first hand. They bury you in a law suit, wrong or right is not the point. These companies have a huge lawyer group and bat you around for fun. This doesn't take into account the fact that Twitter is certainly
[twitter-dev] Re: Rate Limiting Question
Just to make things crystal clear, it should be stated that the 20k rate limits apply only to GET requests to the so-called REST-API. Other request types (I.e., POST) and / or other APIs (I.e., search, streaming) have other rate limits. Jim Renkel On Aug 13, 3:58 pm, Chad Etzel c...@twitter.com wrote: Hi There, What you all have been confirming is correct. The intended behavior is 20k per IP unauthenticated, and 20k per IP *per user* authenticated. This is not a bug. -Chad On Thu, Aug 13, 2009 at 4:43 PM, Abraham Williams4bra...@gmail.com wrote: I've been reading I have confirmed emails from 5 different threads for the last 2 weeks. Can we hold off until Chad gets back to us with an official answer. :) Thanks Abraham 2009/8/13 Dewald Pretorius dpr...@gmail.com Craig, I just ran a test, and I can also confirm what you have found. Unauthenticated calls decrease per IP 20,000 Authenticated calls decrease per-IP per-user 20,000 Dewald On Aug 13, 4:27 pm, CaMason stasisme...@googlemail.com wrote: The behaviour at the moment is definitely as-described above: Unauthenticated calls decrease IP 20,000 Authenticated calls decrease per-user 20,000 My app only uses authenticated calls during normal use, and the IP- based limit isn't decreasing at-all 20,000 per-user is pretty silly - With 1000 users, I would be allowed to make 5,555 calls per second. A max of say 500 authenticated calls per-user would be more sensible, and would allow apps with many users to scale :) -Craig -- Abraham Williams | Community Evangelist |http://web608.org Hacker |http://abrah.am|http://twitter.com/abraham Project |http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: Early developer preview: Retweeting API
I have both practical and philosophical concerns and questions with this proposal. Since I'm a little late in commenting on this, some of these have already been raised. Where I know that is the case, I'll keep it short, but include it to show my support (or not) of the issue. This post contains practical issues. A companion post will contain philosophical issues. 1. When a retweet is created it is assigned an ID number, just like a status update. Are retweets and status updates numbered from the same sequence of numbers, or separate ones? I mainly ask out of curiosity, but there are some implications as shown below. 2. Is there a limit on the number of times a status update can be retweeted? Again, curiosity, but with implications. 3. In the UI, if a status update is shown that has been retweeted, are all retweeters of the update listed, or, e.g., just ones that I follow? If all retweeters are listed, what if the status update was retweeted, say, 1,000 times? 10,000 times? If just retweeters that I follow are listed, can I somehow see a list of all the retweeters? 4. The response to the status/retweet method provides details about the retweet that was created. Does it also include details on previous retweets of the status update? 5. In the response to the statuses/home_timeline, statuses/ retweeted_by_me, statuses/retweeted_to_me, and statuses/retweets_of_me methods, how are multiple retweets of the same status update encoded? I far as I could see, none of the examples addressed this. Is the status update repeated once per retweet? Or are multiple retweets listed under one instance of the status update that was retweeted? In the latter case, the response would presumably look like: ?xml version=1.0 encoding=UTF-8? statuses status ... user ... /user retweet_details ... [details of 1st retweet] /retweet_details retweet_details ... [details of 2nd retweet] /retweet_details ... /status /statuses I could be wrong, but I don't think this is valid XML. I think ya need to have another level of grouping, as in: ?xml version=1.0 encoding=UTF-8? statuses status ... user ... /user retweets retweet_details ... [details of 1st retweet] /retweet_details retweet_details ... [details of 2nd retweet] /retweet_details ... /retweets /status /statuses 6. Each XML retweet_details section takes around 100-200 characters to encode. If a response that includes retweet_details only returns retweets for those I follow, if I have 20 retweeted status updates each with, say, 20 retweets, that's 20*20*100=4 plus characters required for the response. Even if the response only includes 1 retweeted status update, but it has been retweeted 10,000 times (Not unheard of! And IMHO it's more likely to happen once this is deployed and folk start writing retweebots), that's 1*1*100=100 plus characters. I think there's a problem here that needs to be addressed. 7. If retweets and status updates are numbered from the same sequence of IDs, then presumably statuses/destroy can be used to delete a retweet. If retweets and status updates have separate ID sequences, then I don't see any way to delete a retweet. I think the ability to delete a retweet is essential! BTW, I don't see any delete capability in the proposed UI. 8. If a protected user retweets a status update of a non-protected user, will the protected user always / sometimes / never be listed as a retweeter of the public user's status update? 9. Conversely, if a non-protected user retweets a status update of a protected user, will the protected status update always / sometimes / never be included in the various timelines of the non-protected user? 'Nough for now. I'll probably have more as I think this through more. Comments expected and welcome. Jim Renkel On Aug 13, 3:52 pm, Marcel Molina mar...@twitter.com wrote: Retweetinghas become one of the cultural conventions of the Twitter experience. It's yet another example of Twitter's users discovering innovative ways to use the service. We dig it. So soon it's going to become a natively supported feature on twitter.com. It's looking like we're only weeks away from being ready to launch it on our end. We wanted to show the community of platform developers theAPIwe've cooked up forretweetingso those who want to support it in their applications would have enough time to have it ready by launch day. We were planning on exposing a way for developers to create a
[twitter-dev] Re: Early developer preview: Retweeting API
This post, containing philosophical issues with the proposed retweet API, is the promised companion to my post containing practical issues. I realize this retweeting API and UI are probably a fait a complis (sp?), modulo addressing practical concerns that I and others have raised, but I'll throw out my two cents worth anyhow. In summary, I don't like this proposal very much. As someone else has pointed out, I think it's akin to driving a tack with a sledge hammer. I see very little wrong / missing with the current retweeting conventions, and I think the twitter community would be better served by addressing these problems / shortcomings that creating something new out of whole cloth. My biggest dislike is that there is no capability to add to the retweet, only exactly duplicate what has already been said. Others have said more eloquently than I could the value of being able to add to a retweet, and I fully support pretty much everything that has been said here. Ya there's a problem with the length of some retweets that have been added to, but the solutions already in place seem to be satisfactory. Was this the real problem that twitter was trying to solve that lead to this API? There is value in knowing that a status update is a retweet, but that could have been much more easily done by adding a new parameter to the status/create method than creating a whole new method, and reporting it's value whenever the status update is reported. AND, it could have been done with 100% backward compatibility, at least as I understand backward compatibility. The implications of requiring changes to existing applications are enormous. Ya there are currently several conventions for indicating a retweet: RT; [unicode recycle symble]; etc. Again, a new parameter to the status/create method solves the problem quite simply and elegantly. AND reduces the problem with the length of retweets. There is value in knowing who has retweeted a tweet, but there is more value in knowing who has responded to a status update in any way. That could have been provided as a status/responses method that I and others have proposed many times, and would result in more value than just being able to find out who has retweeted a status update. I predict, as others have, that retweebots will proliferate and vastly expand and complicate the spam and issues of dealing with it that are already present. Applications and sites that already have a retweet capability will have to change the name of their capability, leading to user confusion, AND implement this new retweeting scheme, leading to even more user confusion. If there were simply a new parameter to the status/create method, I think existing applications and sites would jump all over it, with very little user confusion. When I get there, I know that my site, http://twxlate.com, will definitely implement the existing retweeting conventions (I will have to come up with some other name for it.) and will probably, but not certainly, implement the new API if it is really introduced essentially as it is now. At least I'll be able to do that with less confusion than if I had already implemented the existing retweeting conventions. Again, 'nough for now, but, again, I'll probably come up with more as I think about this more. As always, comments expected and welcome. Jim renkel On Aug 13, 3:52 pm, Marcel Molina mar...@twitter.com wrote: Retweetinghas become one of the cultural conventions of the Twitter experience. It's yet another example of Twitter's users discovering innovative ways to use the service. We dig it. So soon it's going to become a natively supported feature on twitter.com. It's looking like we're only weeks away from being ready to launch it on our end. We wanted to show the community of platform developers theAPIwe've cooked up forretweetingso those who want to support it in their applications would have enough time to have it ready by launch day. We were planning on exposing a way for developers to create a retweet, recognize retweets in your timeline and display them distinctively amongst other tweets. We've also got APIs for several retweet timelines: retweets you've created, retweets the users you're following have created, and your tweets that have been retweeted by others. - Creating Retweets TheAPIdocumentation for creating retweets can be found here: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweet Reminder: Making requests to /statuses/retweet won't work yet as the feature has not launched. - Consuming Retweets in the Timeline 1) Retweets in the new home timeline We don't want to break existing apps that don't addretweetingsupport or create a confusing experience for that app's users. So the /statuses/friends_timelineAPIresource will remain unchanged--i.e. retweets will *not* appear in it. For those who *do* want to support retweets, we are adding a new (more aptly named) /statuses/home_timeline resource.
[twitter-dev] Re: Early developer preview: Retweeting API
Brian, Good catch on deleting a retweeted tweet! It was on my list of issues, by I forgot to include it in my post. Hopefully, the twitter folk will respond to this as fast as they added retweet_id so ya can delete retweets! :-) Jim On Aug 17, 1:33 pm, Brian Smith br...@briansmith.org wrote: jim.renkel wrote: 7. If retweets and status updates are numbered from the same sequence of IDs, then presumably statuses/destroy can be used to delete a retweet. If retweets and status updates have separate ID sequences, then I don't see any way to delete a retweet. I think the ability to delete a retweet is essential! BTW, I don't see any delete capability in the proposed UI. It is important to be able to un-retweet. I would also like to know how it is done. 8. If a protected user retweets a status update of a non-protected user, will the protected user always / sometimes / never be listed as a retweeter of the public user's status update? 9. Conversely, if a non-protected user retweets a status update of a protected user, will the protected status update always / sometimes / never be included in the various timelines of the non-protected user? Protected users' activities should never be disclosed to people outside their list of approved followers. The privacy advantage of the current RT @foo convention is that the reader never knows if @foo actually said what was retweeted unless @foo approved him as a follower. Here's another sticky issue, related to that: What happens when a user posts a tweet, and then a bunch of people retweet it, and then the user deletes the tweet? The original poster doesn't want to be associated with the message anymore and would rather that message not exist. But, the re-tweeters expect to have an archive of everything they retweeted. Regards, Brian
[twitter-dev] Re: Early developer preview: Retweeting API
Marcel: thank you for the quick response to my questions. Not surprisingly, your answers have raised a couple of more questions. :-) 1. What happens if I give a retweet id number to the status/show method? An error? The retweeted status message is returned along with information about all of its retweets? I'm really hoping for the second option here, and, if that is not the case currently, I would encourage twitter to make that enhancement. It seems to me to be natural to want information on one specific retweet, just as one can get specific information on one specific status update. For the next 2 questions, assume A is following B and C, that B has retweeted a status update say two days ago, and C has retweeted the same status update yesterday. 2. In the response to a statuses/home_timeline request for user A, will the retweeted status update and all its retweeting information be duplicated at the two appropriate places in the timeline, once for B and once for C? Or will one or the other be elided? 3. If the answer to 2, above, is the retweeted status update is duplicated, does the retweeting information reflect the state of the twitterverse as it exists at the time the request is made or the state at the time the retweet was created? Specifically, will the retweeting information for B's retweet show that C has also retweeted it, even though C hadn't yet retweeted it when B did? 4. Assume count=20 is specified on the statuses/home_timeline request. Does the retweeted status update and all of its retweets count as just 1 of the 20 status updates in the response (i.e., the response could have more than 20 elements, potentially way more, but all of the retweets of a status update would appear in one page of the response)? Or does each retweet count as 1 of the 20 (i.e., the response will have only 20 elements, but the retweets of a single status update could be spread across many, potentially very many, pages)? I think it would have to be the former, as Clients may [only] request up to 3,200 statuses via the page and count parameters for timeline REST API methods. (Quoted from the API documentation under 6) There are pagination limits.), and if it were the latter ya couldn't even return all the retweet information for a status update that was retweeted more than 3200 times (Which DOES happen.). 5. statuses/home_timeline is like statuses/friends_timeline but with retweets. There is no method that is like statuses/ user_timeline but with retweets. It can be synthesized by merging the results of statuses/user_timeline and statuses/retweeted_by_me method requests, but only for the authenticating user: the statuses/ retweeted_by_me method does not take id and user_id parameters as the statuses/user_timeline method does. I think there's something missing here: if I can see any users status updates, why can't I see their retweets? 6. There are no methods like statuses/mentions and favorites but including retweets (Or do those methods' results now include retweets?). I see no way at all of synthesizing these. I think these need to be provided for completeness. 7. Similarly, I'm guessing that statuses/friends and statuses/ followers responses don't include retweets (But if a user's last update was a retweet, what do they report? The last update that wasn't a retweet?). Again, I don't see a way of synthesizing these, and I think methods that do include retweets need to be provided for completeness. The reason for wanting the completeness is to avoid user confusion. Users will get used to seeing retweets, when they exist, when the home timeline is displayed, and assume that if none are displayed, none exist. I fear that they will then make that same assumption when mentions, favorites, friends, and followers are displayed: no retweets displayed, ergo no retweets exist. That may or may not be correct. 'Nough for now. Comments expected and welcome. Answers demanded! -) Jim Renkel On Aug 17, 1:56 pm, Marcel Molina mar...@twitter.com wrote: Thanks for your questions. Responses inline... On Mon, Aug 17, 2009 at 10:31 AM, jim.renkeljames.ren...@gmail.com wrote: I have both practical and philosophical concerns and questions with this proposal. Since I'm a little late in commenting on this, some of these have already been raised. Where I know that is the case, I'll keep it short, but include it to show my support (or not) of the issue. This post contains practical issues. A companion post will contain philosophical issues. 1. When aretweetis created it is assigned an ID number, just like a status update. Are retweets and status updates numbered from the same sequence of numbers, or separate ones? I mainly ask out of curiosity, but there are some implications as shown below. Tweets and retweets are currently numbered from the same sequence of numbers. 2. Is there a limit on the number of times a status update can be retweeted? Again, curiosity, but with implications. No.
[twitter-dev] Re: Early developer preview: Retweeting API
Another question occurred to me as I think about this more and start designing the code that I will use with my site (http://twxlate.com). The statuses/retweeted_by_me method complements the statuses/ user_timeline method: user_timeline Returns the 20 most recent statuses posted from the authenticating user.; retweeted_by_me Returns the 20 most recent retweets posted by the authenticating user.. However, with the user_time method, It's also possible to request another user's timeline via the id parameter.. The retweeted_by_me method does not have this option, and I think it should. Can this be added? I think maybe the statuses/retweets_of_me method should also have an optional id parameter, but I could be wrong about this. The statuses/retweeted_to_me method also does not have an optional id parameter, but the absence here is, I think, correct. Comments expected and welcome. Jim On Aug 18, 7:35 pm, jim.renkel james.ren...@gmail.com wrote: Marcel: thank you for the quick response to my questions. Not surprisingly, your answers have raised a couple of more questions. :-) 1. What happens if I give aretweetid number to the status/show method? An error? The retweeted status message is returned along with information about all of its retweets? I'm really hoping for the second option here, and, if that is not the case currently, I would encourage twitter to make that enhancement. It seems to me to be natural to want information on one specificretweet, just as one can get specific information on one specific status update. For the next 2 questions, assume A is following B and C, that B has retweeted a status update say two days ago, and C has retweeted the same status update yesterday. 2. In the response to a statuses/home_timeline request for user A, will the retweeted status update and all its retweeting information be duplicated at the two appropriate places in the timeline, once for B and once for C? Or will one or the other be elided? 3. If the answer to 2, above, is the retweeted status update is duplicated, does the retweeting information reflect the state of the twitterverse as it exists at the time the request is made or the state at the time theretweetwas created? Specifically, will the retweeting information for B'sretweetshow that C has also retweeted it, even though C hadn't yet retweeted it when B did? 4. Assume count=20 is specified on the statuses/home_timeline request. Does the retweeted status update and all of its retweets count as just 1 of the 20 status updates in the response (i.e., the response could have more than 20 elements, potentially way more, but all of the retweets of a status update would appear in one page of the response)? Or does eachretweetcount as 1 of the 20 (i.e., the response will have only 20 elements, but the retweets of a single status update could be spread across many, potentially very many, pages)? I think it would have to be the former, as Clients may [only] request up to 3,200 statuses via the page and count parameters for timeline RESTAPImethods. (Quoted from theAPIdocumentation under 6) There are pagination limits.), and if it were the latter ya couldn't even return all theretweetinformation for a status update that was retweeted more than 3200 times (Which DOES happen.). 5. statuses/home_timeline is like statuses/friends_timeline but with retweets. There is no method that is like statuses/ user_timeline but with retweets. It can be synthesized by merging the results of statuses/user_timeline and statuses/retweeted_by_me method requests, but only for the authenticating user: the statuses/ retweeted_by_me method does not take id and user_id parameters as the statuses/user_timeline method does. I think there's something missing here: if I can see any users status updates, why can't I see their retweets? 6. There are no methods like statuses/mentions and favorites but including retweets (Or do those methods' results now include retweets?). I see no way at all of synthesizing these. I think these need to be provided for completeness. 7. Similarly, I'm guessing that statuses/friends and statuses/ followers responses don't include retweets (But if a user's last update was aretweet, what do they report? The last update that wasn't aretweet?). Again, I don't see a way of synthesizing these, and I think methods that do include retweets need to be provided for completeness. The reason for wanting the completeness is to avoid user confusion. Users will get used to seeing retweets, when they exist, when the home timeline is displayed, and assume that if none are displayed, none exist. I fear that they will then make that same assumption when mentions, favorites, friends, and followers are displayed: no retweets displayed, ergo no retweets exist. That may or may not be correct. 'Nough for now. Comments expected and welcome. Answers demanded! -) Jim Renkel On Aug 17, 1:56 pm, Marcel Molina
[twitter-dev] Re: help retrieving tweets from other users!
Yes, the *per request* limit is 200, but using the page parameter you can retrieve up to the last 3200 status updates. See http://apiwiki.twitter.com/Things-Every-Developer-Should-Know#6Therearepaginationlimits for more information. I've implemented and tested this in my site (http://twxlate.com), and it seems to work as advertised. Hope this helps, Jim On Aug 20, 9:49 am, raashid bhatt raashidbh...@gmail.com wrote: no u didnt understood me .. i know per request the limit is 200 but what about the next 200 tweets how can i get those ( of the other user) On Aug 20, 7:06 am, Duane Roelands duane.roela...@gmail.com wrote: My understanding is that 200 is the limit for retrieving status updates via the REST API. On Aug 20, 4:38 am, raashid bhatt raashidbh...@gmail.com wrote: Hi all i am developing a Desktop client of twitter for self use its actually my first time working on twitter API i want get tweets from other user for that i use user_timeline REST method but for that i can only view latest 200 tweets for that particular user and page parameter don't works with user_id combinations so please suggest me how can i tackle this problem Thanks!
[twitter-dev] Re: help retrieving tweets from other users!
raashid, Multiple parameters in the same request are separated by 's, not another ?. :-) Try these, they seem to work for me: http://twitter.com/statuses/user_timeline.xml?id=raashidbhattpage=2 or http://twitter.com/statuses/user_timeline.xml?screen_name=raashidbhattpage=2 Jim On Aug 20, 1:13 pm, raashid bhatt raashidbh...@gmail.com wrote: here getting page three from my account which ain't protected dosent work it asks for password and username http://twitter.com/statuses/user_timeline.xml?id=raashidbhatt?page=2 orhttp://twitter.com/statuses/user_timeline.xml?screen_name=raashidbhat... On Aug 20, 9:29 am, jim.renkel james.ren...@gmail.com wrote: Yes, the *per request* limit is 200, but using the page parameter you can retrieve up to the last 3200 status updates. Seehttp://apiwiki.twitter.com/Things-Every-Developer-Should-Know#6Therea... for more information. I've implemented and tested this in my site (http://twxlate.com), and it seems to work as advertised. Hope this helps, Jim On Aug 20, 9:49 am, raashid bhatt raashidbh...@gmail.com wrote: no u didnt understood me .. i know per request the limit is 200 but what about the next 200 tweets how can i get those ( of the other user) On Aug 20, 7:06 am, Duane Roelands duane.roela...@gmail.com wrote: My understanding is that 200 is the limit for retrieving status updates via the REST API. On Aug 20, 4:38 am, raashid bhatt raashidbh...@gmail.com wrote: Hi all i am developing a Desktop client of twitter for self use its actually my first time working on twitter API i want get tweets from other user for that i use user_timeline REST method but for that i can only view latest 200 tweets for that particular user and page parameter don't works with user_id combinations so please suggest me how can i tackle this problem Thanks!
[twitter-dev] Re: Developer Preview: Geolocation API
Um, I don't see any way for a user to turn the geo_enabled attribute on and off. Oversight, I hope? Jim On Aug 20, 4:18 pm, Joel Strellner j...@twitturly.com wrote: Hi Ryan, Will this data be available in the streaming API too? -Joel On Thu, Aug 20, 2009 at 2:11 PM, @epc epcoste...@gmail.com wrote: Will twitter validate the coordinates (ie, what will the API do when I pass lat=777long=-666)? If the coordinates are invalid, will the status get posted or will the entire request get rejected with a 4xx code? If a user has not enabled geolocating (geo_enabledfalse/ geo_enabled), what happens if I pass in coordinates for that user? Silently ignored? Geo data will be attached to individual tweets and not users, right? This will have no effect on the location field in a user profile? -- -ed costello
[twitter-dev] Re: Developer Preview: Geolocation API
Is there any possibility of a test site, with these API response changes, being made available before the changes are introduced to the real site? This would allow us to test our sites and applications against the test site and fix any bugs and bombs before users would otherwise experience them when the changes go live on the real site. My code is written very defensively and is generally OK with things like this, but the only real way to know for sure is to test it. This kind of testing is better done in a controlled environment than in the real live environment. It is not necessary that the test site accept geolocation updates, only that it return status elements with geo sub-elements, user elements with geo_enabled sub-elements, etc. The test site could even have a very small user database, it wouldn't need the entire live twitter database. Not would it need to support API requests that are POSTs, only GETs. Even if the test site is only available as little as 1 or 2 days before the real site goes live, given reasonable advance notice (1 week?) as to when the test site will be available, this could greatly smooth out the introduction of this really cool feature for all of us: twitter, twitter partners, and twitter users. Anything that could be done here would be greatly appreciated by me, and I believe the whole twitter development community. Comments expected and welcome. Jim Renkel On Aug 21, 11:25 pm, Raffi Krikorian ra...@twitter.com wrote: Hi Damon. Yup - we've started updating the docs. Generally, there will always be a geo in the status (it may just be empty, however, if there is no geolocated information attached), and there will always be a geo_enabled on every user which is a boolean representing whether the user has enabledgeolocationon his or her account. On Aug 21, 2009, at 6:46 PM, Damon Clinkscales sca...@pobox.com wrote: On Aug 20, 3:46 pm, Ryan Sarver rsar...@twitter.com wrote: We wanted to give you all a heads up on a cool new feature that is coming soon -Geolocation. We have also updated the wiki to reflect what theAPIwill look like when it launches, so check it out and let us know if you have any questions:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A- statuses%C2%A0u...http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0ve ... Ryan, Very cool stuff. Looking forward to it. I'm assuming that you'll update the wiki (andAPIwhen it launches) such that everywhere a status element is returned, it will contain a geo element? Thanks, -damon
[twitter-dev] Re: I can't use OAuth and I want to apply source(from[myApp]) [And more!!!]
I have a similar, perhaps broader, issue and a suggestion for a solution. My problem is that my site, http://twxlate.com, supports 40+ languages for its user interface, not just the two supported by twitter.com. By that I mean that the user interface is available in 40+ languages, not just that it can handle information obtained from twitter that could be in any one of the 40+ languages. The site currently supports Basic Authentication, with the prompts in one of the 40+ languages of the user's choosing. It works quite nicely, thank you, for user's that are comfortable in giving the site their user id and passwords. When I add support for OAuth, which I am doing, I can present the link to twitter's OAuth page in that language of the user's choosing. But the OAuth page itself is only available in two languages. This could result in a roadblock to users that are not fluent in either of those two languages using my site. Especially when twitter turns off Basic Authentication sometime in the (hopefully distant :-) ) future. My suggestion for a fix to this (and other related problems) is to add a method to the API that requires only Basic Authentication and that returns the same information as the OAuth callback (i.e., consumer secret) just as if the authenticated user had gone to the OAuth page and approved the application to access twitter on its behalf. My rational for this is as follows: if the user was comfortable, for whatever reason, with giving the information necessary to authenticate them (i.e, user id and password) to my site and twitter accepts it on a request by request basis with Basic Authentication now, why should they not continue to accept it in the future? If twitter wants to do away with Basic Authentication on a request by request basis and require OAuth preauthorization for API requests, why should they not accept a Basic Authorization bridge into OAuth for users that are comfortable, for whatever reason, with giving the necessary information to the application that will access twitter on their behalf? BTW, this solution would also solve the much discussed problems of client applications, especially mobile device applications, that have difficulty getting back and forth to the twitter OAuth page because of, e.g., limited device functionality. Comment welcome and definitely expected on this one! :-) Jim Renkel P.S.: How do users that aren't fluent in English or Japanese get twitter accounts in the first place? I'll leave a proposal for that to another day, another post. On Aug 22, 12:40 am, bang bang...@gmail.com wrote: I'm the builder of Twitese (http://twitese.appspot.com/), a chinese web client for Twitter. I know that if a new web appwantto show from [myApp], the only way is touseOAuth, but in china that's infeasible, because twitter has been block in china, chinese people can not access twitter.com touseOAuth. So Ican'tuseOAuth. The only way to login isuseHTTP Basic, as the result, statuses post from Twitese just show from web. So Iwanttoapplyasourcefor my Twitese, is that possible?
[twitter-dev] Re: Stop playing around with Source parameters
Hmm, using some command line test programs I've developed, I'm still getting 'rel=nofollow'. For example: -- Public timeline 20 statusses Status 0: from HandsomeSmokes, 35229362, Mula Smokes , Brooklyn userImgURLhttp://a3.twimg.com/profile_images/372445265/IMG00064_normal.JPG (en) Wass Poppin Yall..I Go By Handsome Smokes..Im Living Life From A Whole Different Angle..If Needed Hit Me Up Aim - Smokes90z ID 3560548081 created 1 second ago in reply to 3557116376 by 25442179 (Ms_KEN_NSL) with a href=http://sidekick.com/; rel=nofollowSidekick/a (en) a href='prf?u=Ms_KEN_NSL'@Ms_KEN_NSL/a BuT Th3 OtH3r OnE iiS ThAt Th3y ZeAdAsS ThiiNk Th3y PoPPiiN WiiTh OuT Us BoYs SaYiiN ShiiT TeW Em 0 URLs ... Status 12: from petrah, 14461792, Petra Hubbeling, Amsterdam userImgURLhttp://a3.twimg.com/profile_images/341156029/collage2_normal.jpg (nl) Oprichter van Boeddhisness, netwerker op gebied van boeddhisme, marketing, communicatie, sales en recruitment. Bestuurslid Boeddhistische Unie Nederland (en) Founder of Boeddhisness, networker in terms of Buddhism, marketing, communications, sales and recruitment. Netherlands Board Buddhist Union 0.3881578947368421 ID 3560613438 created 2 seconds ago in reply to 3560539429 by 15481144 (LieveLiesje) with a href=http://www.tweetdeck.com/; rel=nofollowTweetDeck/a (nl) a href='prf?u=LieveLiesje'@LieveLiesje/a Jeemig. wat ongezellig en ik maar denken dat a href='prf? u=tonvanderhoeve'@tonvanderhoeve/a zo romantisch was, heeft hij ze niet eens bij zich? (en) a href='prf?u=LieveLiesje'@LieveLiesje/a Jeemig . some unsociable a href='prf?u=tonvanderhoeve'@tonvanderhoeve/a and I think it was so romantic, he does not agree with them? 0.5909090909090909 0 URLs ... Jim Renkel On Aug 26, 11:09 am, John Adams j...@twitter.com wrote: This was patched yesterday afternoon. -j On Aug 25, 2009, at 11:38 PM, Costa Rica wrote: Hello Twitter, Any official word on this apparent vulnerability around the Source parameter and cross site scripting? http://www.davidnaylor.co.uk/massive-twitter-cross-site-scripting-vul... TCI On Aug 22, 9:46 am, Chad Etzel jazzyc...@gmail.com wrote: Hi All, We did not intend for the nofollow string to be included in API results. It is on our list to fix. In the meantime you will need to parse around it. Thanks, -Chad On Sat, Aug 22, 2009 at 11:20 AM, Costa Ricaticoconid...@gmail.com wrote: Thanks to all for your suggestions on how to parse, remove nofollows or extract the URL, but that's not the bottomline of my message. There are some source parameters that are posting automated crap constantly, and since I run a trending engine I continuously exclude these tweets. Yes I can parse and str replace and even base myself only on the URL, but the 2 side effects are that my processing time increase (a simple string compare vs a regex) - which becomes significant as I increase the volume I intend to process, and that the URL's themselves can easily change to workaround these filters. I will keep my simple compare - the sites are not that many and the processing toll of regex'ing this does not merit it - but I would appreciate some word from Twitter when the source parameter is being changed, or else some sourceid that is stable. R On Aug 21, 10:17 pm, TCI ticoconid...@gmail.com wrote: Recently you added nofollow's, and now you moved the nofollow after the href. Some of us filter these out and you changing them is only making it more complicated. Please make up your mind and stop changing these... a href=http://fun140.com/;Fun140/a a rel=nofollow href=http://fun140.com/;Fun140/a a href=http://fun140.com/; rel=nofollowFun140/a
[twitter-dev] Re: Pass credentials to browser
Fortunately, when I tried that it didn't work. Jim On Aug 26, 11:29 am, JDG ghil...@gmail.com wrote: Yeah there is, albeit not a very nice one: You can dohttp://user:p...@site/ On Wed, Aug 26, 2009 at 09:24, Josh Roesslein jroessl...@gmail.com wrote: How is that scrapping? He is just launching IE and pointing the browser at a twitter web page for viewing. As long as he does not parse that page for data and just uses it to display that's not scrapping. Now I don't think there is a legit way of passing login credentials, that the user will have to do on there own. On Wed, Aug 26, 2009 at 8:15 AM, Stuart stut...@gmail.com wrote: 2009/8/26 balu reghu baluk...@gmail.com: Hi all, Can i pass my credentials to browser.I am working on a twitter application. On a click i am trying to show the twitter site. If i have the credentials with me.Can i make the user view his tweets without login (again) this is my code on a click Process.Start(@\Windows\iexplore.exe, http://m.twitter.com/search/ users?q= + tbsearch.Text); In this case the browser will show a popup .asking for user name and password.Is there any way to pass the credentials? That is not an API call so what you're doing is scraping the Twitter site. They don't like you doing that and it will likely get your IP blocked if you keep doing it. -Stuart -- http://stut.net/projects/twitter/ -- Josh -- Internets. Serious business.
[twitter-dev] Re: New ReTweet API
I asked this, and similar but more detailed questions, in my Aug 18, 7:35 pm post to this thread: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/1e07e332ec3d449d/2d10a6a22e55133e?lnk=gstq=ReTweet+API#2d10a6a22e55133e but, unfortunately, have not yet received an answer, at least none that I can find. Could someone from twitter (Marcel Molina?) please address these issues? I think they are pretty important. I need to know the answers to be able to design support for retweets in my site (http://twxlate.com). I would hope I wouldn't have to resort to experimentation once this feature is deployed at twitter.com to get answers to what I think are pretty fundamental questions. Thanks in advance, Jim Renkel On Aug 14, 1:35 pm, Houshang Nayeb shang...@gmail.com wrote: I have the following question: If one of my tweets is retweeted multiple times, what will be the return value of “retweets_of_me.format” ? Will it be one record with multiple “retweet_details” sections? If yes, will there be a “count” for the number of times it has been retweeted? If no, then what happens? Thanks!
[twitter-dev] Re: if you will be using the Geolocation API ...
Raffi, I fully understand the concern about privacy. To that end, here's something you may want to consider: Have application / web-site over-rides of the geo-code enable be another option on OAuth. This way a user can control the creation of geo-coding in their tweets on a finer grain basis. The profile and OAuth enables would be ANDed: the user has to both grant permission in their profile and via OAuth to allow a client to create tweets with geo-coding for them. If this is done, it may then be reasonable to have the profile default be enabled rather than disabled, with the OAuth default being disabled. The user would have explicitly check a box or something during their OAuth dialogue to grant the client permission. Just a thought. Comments welcome. Jim Renkel On Sep 1, 6:08 pm, Raffi Krikorian ra...@twitter.com wrote: hey jim. 1. the user.location is a completely separate entity (for now) implies that maybe sometime in the future it may be used, e.g., to provide a default geo-coded location for a tweet. I would suggest that if the user's profile location if ever geo-coded, that geo-code should be added to the user objects returned by API calls, at least the users/show method. Users will want to know what may be, e.g., added to their tweets without having to generate a test tweet to find out. 2. Having the user's profile location geo-coded and returned in API calls would be very useful now. Yeh, twitter client web-sites / applications can do it for themselves (Mine certainly will if twitter doesn't do it.), but may come up with different / inconsistent results. And, trust me, it ain't as easy to get good results as it might first appear. To maximize use and consistency, it would be great if twitter did the geo-coding and supplied it to everyone. these are both great ideas. right now, the geolocation API is really focused on tweet-level information -- but we're actively thinking about what's next. 3. Will twitter client web-sites / applications be able to turn the geo-location feature on for their users, or do the users have to go to twitter.com with a browser to do this? My concern here is that twitter.com only supports two languages (English and Japanese) for its UI, where my site (http://twxlate.com) supports these and over 40 more. Unless the user is fluent in English or Japanese, they won't be able to turn it on. I've already run into similar problems as I'm rolling out test versions of OAuth support. unfortunately not. as we're pretty sensitive to our user's privacy, for now, a user will have to go to twitter.com with a browser to turn on the setting (remember, by default it is off). if you have any suggestions on how to make this user interaction better in the future, i would be eager to hear them! As I've written some pretty spiffy geo-coding applications for other purposes, I plan on doing some pretty spiffy geo-coding stuff with twxlate.com. But it needs to be usable, or users won't use it and / or may be annoyed by it. I would hate for that to happen to what promises to be a really neat feature. cool! well - i hope what we're doing is usable! if not, just keep blasting me about it. threads like these on the mailing list are awesome. -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Kudos to Matthias Kaeppler for signpost Open Authentication Java library
My website (http://twxlate.com) now supports Open Authentication with twitter, and it was way easier than I expected, thanks to the signpost library from Matthias Kaeppler. It took me longer to convert the code I already had for Basic Authentication to Apache Http Components 4.x than it did to subsequently add Open Authentication support. The signpost library is well documented, and works as documented. I enthusiastically endorse it and recommend it to anyone that is looking for a Open Authentication Java library. Again, kudos to Matthias. And, a very, very big thanks! I suppose that now that the web-site could create tweets with their source listed as twxlate rather than API, I'll have to actually support creating tweets and DMs. :-) Jim
[twitter-dev] questions on statuses/friends, statuses/followers, and blocks/blocking method
The blocks/blocking method appears to be similar to the statuses/ friends and statuses/followers methods, but I believe the documentation is incomplete for all three. According to the API spec, each call to statuses/friends and statuses/ followers returns a page of up to 100 users (and their most recent statuses). Pages will contain less than 100 statuses if either a suspended user is (not) present in the page, or the page is the last page. A maximum of 3200 users / statuses can be retrieved. Thus the maximum value of the page parameter would appear to be 32. However, as suspended users are elided from the returned information, if the user has 3200 friends / followers or more, is it then possible that it would take more than 32 pages to get the 3200? If so, how does one easily and reliably determine that a page is the last page? Do you just keep asking for the next page until, e.g., you get a page with 0 users and then you've gone one too far? Or is the 3200 maximum reduced by the number of suspended users? Again according to the API spec, each call to blocks/blocking returns up to 20 users (and their most recent statuses), and the method supports a page parameter. Are suspended users elided from the returned information, as with the statuses/friends and statuses/followers methods? Is there a maximum of 3200 users / statuses? Is the maximum value of the page parameter then 160? And again, how can one easily and reliably determine that a page is the last page? BTW, with a page size of 20 and a maximum of 3200, a user with a lot of blocked users may easily exceed the rate limit of 150 requests per hour, even with only one attempt to get all the blocked users. Is it possible to get the maximum page size increased to 200, both for consistency and to avoid a possible rate limit? I may be wrong, but I think it's unlikely a user would have 3200 blocked users, at least with the current usage of blocking. But I need the answers to these questions so I can effectively program the use of these methods. I hope I can get definitive answers from twitter on this (And maybe an update to the documentation?), but any insight from anyone on this will be greatly appreciated. Thanks in advance, Jim Renkel
[twitter-dev] Re: Can we update geo_enabled field in account profile via API ?
I have suggested previously that the capability of an application to geo-code a users tweets and the capability of an application to opt-in to geo-coding for a user be made OAuthorizable. The application would request these capabilities when registering. If twitter didn't trust the application, it wouldn't grant them. If an application were granted those capabilities when registering, then when a user signed in with OAuth for that application they would be allowed to either authorize the application to use them or not. Thus, the user interface would be made more complicated only for applications that needed it. I think this proposal is a reasonable compromise between twitter's and users' concerns and developers desires. Comments? Jim Renkel On Sep 29, 1:47 am, Abraham Williams 4bra...@gmail.com wrote: My understanding is Twitter wants the opt-in to be explicitly done by the user. If it is changeable through the API apps could enable it without the consent of the user. Abraham On Mon, Sep 28, 2009 at 13:03, CodeWarden paul0...@gmail.com wrote: Hello, Really looking forward to the ability to include lat/long with tweets. However, since all of my users are on mobile devices, it would be most useful if they could change the geo_enabled flag via the API. Before you enable this capability could you allow the update profile method to also update the geo_enabled flag? -Paul -- Abraham Williams | Community Evangelist |http://web608.org Hacker |http://abrah.am|http://twitter.com/abraham Project |http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, WI, United States
[twitter-dev] Question about longevity of geo-coded tweets
I just noticed this in the API wiki, under the statuses/update method: Currently, all geolocated information will be removed after seven days. Two questions: 1. What exactly will be removed: the geocoding attached to the tweet? Or the whole tweet? 2. Why? I.e., why remove the geocoding or the whole tweet? I can think of many use cases where it is important for the geocoding to remain as long as the tweet remains. For example, I take a great vacation picture, upload it to Twitpic, then tweet about it, including where I took it. The location where I took the picture remains the same forever. Why delete the geocoding information from the tweet, or the whole tweet. This will just cause folk to put the geocoding information in the text of the tweet, taking up valuable space and reducing the value of geocoding tweets, and cause developers (Like me, admittedly) to develop applications that put the geocoding in the text of the tweet. With applications like that available, twitter users are less likely to go to the botther of opting-in to twitter geocoding of their tweets. Comments expected and welcome. Jim Renkel
[twitter-dev] Re: Question about longevity of geo-coded tweets
As an alternative to a hard coded 7 days for the interval to the removal of geocoding information from a tweet, I suggest that an optional expires parameter be added to the statuses/update method. The value of this parameter would give the number of days between the tweet creation and when the geocoding would be removed from the tweet. The default value of the parameter, i.e., the value used if the parameter is not present in a statuses/update request, would be 7, in conformance with current policy. An explicit value of 0 would indicate that the geocoding information is never to be removed (But see below.). You may also want to consider a new method that removes the geocoding information from an existing tweet, even if the interval was specified as 0. Obviously, irreversible, like deleting a tweet, and could only be done by the creator of the tweet, like the statuses/destroy method. Comments expected and welcome. Jim Renkel On Sep 29, 12:42 pm, Raffi Krikorian ra...@twitter.com wrote: I just noticed this in the API wiki, under the statuses/update method: Currently, all geolocated information will be removed after seven days. Two questions: 1. What exactly will be removed: the geocoding attached to the tweet? Or the whole tweet? the geocoding attached to the tweet. 2. Why? I.e., why remove the geocoding or the whole tweet? I can think of many use cases where it is important for the geocoding to remain as long as the tweet remains. For example, I take a great vacation picture, upload it to Twitpic, then tweet about it, including where I took it. The location where I took the picture remains the same forever. Why delete the geocoding information from the tweet, or the whole tweet. This will just cause folk to put the geocoding information in the text of the tweet, taking up valuable space and reducing the value of geocoding tweets, and cause developers (Like me, admittedly) to develop applications that put the geocoding in the text of the tweet. With applications like that available, twitter users are less likely to go to the botther of opting-in to twitter geocoding of their tweets. this is being done for privacy issues, and in the future data will be kept for longer once more sophisticated privacy controls are put into place. -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] 3200 users limit gone for cursorized statuses/friends and statuses/followers methods?
Also, apparently the 3200 users limit is no longer in effect for these methods. I was able to successfully request and receive the 32nd 100 user block of @aplusk's followers! Kinda slow, took 168 seconds to retrieve 33 blocks of 100 users (slightly greater than 5 seconds per block; BTW, no retries were involved), but it did return a result that as near as I can tell, not being aplusK (Not that he ever looks at his followers anyhow :-) ), was correct. For grins, I tried to retrieve the 41st block, and gave up after ~45 minutes. So apparently, as previously noted in some discussion of caching somewhere in this group, it slows down considerably the deeper ya go into the list. (TIC: tongue in cheek): On the other hand, all those that have been whining about not being able to get screen names with the social graph methods now have a solution, albeit a slow one! And ya don't just get the screen names, ya get almost everything twitter knows about the user, including their current status! What more could you want! :-) Jim Renkel On Sep 29, 12:40 pm, jim.renkel james.ren...@gmail.com wrote: In working with the new cursorized statuses/friends and statuses/ followers methods, I noticed that in the block of users returned by these methods that contain the last of the users following or followed by the requesting user, the next_cursor value is 0. Is this a reliable, guaranteed indicator of the last block of users, that there's no point in going further 'cause there ain't no further? If so, will the value always be exactly 0 (although without the quotes in the responses, i.e., is a string comparison for 0 safe, or could it be 000, say, in which case a conversion to numeric and a numeric comparison for 0 would be necessary. I would certainly like it to be the former! Either way, string or numeric, if this is a reliable indicator of the last block of users, the documentation should be updated to reflect this. Thanks in advance. Jim Renkel
