Re: [twitter-dev] Re: Snowflake: An update and some very important information

[Tom van der Woerdt]

On 10/20/10 8:12 AM, M. Edward (Ed) Borasky wrote:
>> 6) Why not restrict IDs to 53bits?
>>
>> A Snowflake ID is composed:
>>  * 41bits for millisecond precision time (69 years)
>>  * 10bits for a configured machine identity (1024 machines)
>>  * 12bits for a sequence number (4096 per machine)
>>
>> The factor influencing the length of the ID is the time. For a 53bit
>> ID this
>> would mean only 31bits are available for the time. 31bits is only
>> enough for
>> 24 days (2147483648/(1000*60*60*24)) of time.
>>
>> Reducing the resolution of the timestamp would prevent a K-sorted
>> resolution
>> of 1 second or less.
>>
>> Reducing the configured machine identity or sequence number by 1bit would
>> mean we couldn’t scale Twitter, or operate our infrastructure in an
>> uncoordinated high-available way.
> 
> Interesting ... so you have the theoretical capacity to scale to 2**22
> (about 4 million) tweets per millisecond? Even 4 million tweets a second
> seems unrealistic, as does a single "machine" only being able to
> generate 4096 IDs. I think if you're really expecting this kind of
> volume, the FPGA vendors probably can help you out. We are talking
> clocks and counters, here, right, not Javascript interpreters or robust
> linear regressions? ;-)
> 
> Ah, well, I'll check back on you guys in 69 years to see how you're
> holding up. ;-)
> 

I'd say that you could remove a maximum of 2 bits from the time - this
would divide the 69 years by 4, making it a max of 17 years. By then,
I'd assume that we are past the 53-bit limit.

You could remove 3 bits from the machine ID and 5 bits from the sequence
number. It would mean that there could be only 128 ID servers with 128
IDs per millisecond per machine -> 16 million tweets per second.

In total you would have removed 10 bits from a number that had only 63
bits -> 53 bits. The question is: do you want that? I don't think you
do. I really prefer the current solution.

Tom

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Re: Snowflake: An update and some very important information

[M. Edward (Ed) Borasky]

6) Why not restrict IDs to 53bits?

A Snowflake ID is composed:
 * 41bits for millisecond precision time (69 years)
 * 10bits for a configured machine identity (1024 machines)
 * 12bits for a sequence number (4096 per machine)

The factor influencing the length of the ID is the time. For a 53bit ID this
would mean only 31bits are available for the time. 31bits is only enough for
24 days (2147483648/(1000*60*60*24)) of time.

Reducing the resolution of the timestamp would prevent a K-sorted resolution
of 1 second or less.

Reducing the configured machine identity or sequence number by 1bit would
mean we couldn’t scale Twitter, or operate our infrastructure in an
uncoordinated high-available way.


Interesting ... so you have the theoretical capacity to scale to 2**22  
(about 4 million) tweets per millisecond? Even 4 million tweets a  
second seems unrealistic, as does a single "machine" only being able  
to generate 4096 IDs. I think if you're really expecting this kind of  
volume, the FPGA vendors probably can help you out. We are talking  
clocks and counters, here, right, not Javascript interpreters or  
robust linear regressions? ;-)


Ah, well, I'll check back on you guys in 69 years to see how you're  
holding up. ;-)


--
M. Edward (Ed) Borasky
http://borasky-research.net http://twitter.com/znmeb

"A mathematician is a device for turning coffee into theorems." - Paul Erdos


--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Auto Response - Reply/Follow

[Sruthi]

Dear Support,

We are using Twitter oAuth API for our application.

We are planning to facilitate our Users with Auto-Reply/Follow
features in our website. Please can you confirm us that we are not
violating any Twitter Rules by providing such auto responding service?

Thanks in advance.

- Developer

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] x.co URL no longer recognized automatically

[kprobe]

I was excited to see links via to x.co tags supported automatically
with the New Twitter.
ie when I post a tweet like "Visit x.co/4Hangman", the site reference
was automatically converted into a URL link.

Today this is no longer the case. I have to supply www. or http://
which wastes space.

Is this by design or an oversight with a recent change?

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] friends list in Site Stream

[N]

Hi there,

I've been playing with Site Stream for a bit, and I have a request.

When a client connects to the server, it returns a series of the
friend list for each users. Can you make this optional? Receiving a
lot of friends data for thousands of users is a quite bit of trafic
and wasteful unless it's really needed. I'd be very happy if I
wouldn't have to receive it when I don't need.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Extract a one month social graph around a topic

[Abhi]

Hi,

I am new to the Twitter API world and appreciate your help.

I am trying to do some sentiment analysis around few topics. The
options that I think I have (although dont know if these options
actually exist)

1. download last one month of tweets (related to various topic) and
then run sentiment analysis on them

or

2. run the Search API (w/ query = "topic") several times in a day and
collect the tweets over a period of month and then  do the data
analysis. the problem with this method is that twitter rate limits how
many search query one can make in a day (white-listing seems to be
taking ages)

I am sure several people have done similar things in past. would
really appreciate if you could please share your thoughts/experience.

Cheers
Abhi

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Re: Where to submit a bug report?

[yaemog Dodigo]

Hi,

 I don't know any other way

> to get the statuses of approximately 60 users every minute when my app
> is behind a firewall (preventing OAuth authentication for each
> individual user).  So I use my app's access token/secret to get my
> friends (and their most recent status).
>

This sounds like it should be trivially be done with the streaming api.

cheers

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Snowflake: An update and some very important information

[Matt Harris]

Hey everyone,

Thank you to all of you for your questions, patience and contributions to
this thread.  Hearing your views and knowing how you use the API helps us
provide more information where there wasn't enough, and clarify details
where there was ambiguity.

I've collated the questions i've received from you directly, over Twitter to
@twitterapi and through this list.  I hope the comments below provide enough
information to answer those questions and explain the reasoning being our
decisions.

Thanks for your support and patience,
@themattharris


1) Will search.twitter.com also include id_str and
in_reply_to_status_id_str?
Yes, Search will include the String representations of those IDs.


2) Which fields are affected by this change?
All IDs which are transmitted as Integers will have a String representation
in the API response. Only Tweet IDs (which includes mentions and retweets)
will be moving to new Snowflake IDs. Messages (DMs), Saved Searches and
Users may change to a Snowflake ID scheme in the future but this isn’t
planned for this year.

We are adding String representations of the Integer IDs now so you can
update all of your code to use the String representations throughout. to
allow developers to make the change now for all the ID fields and be
prepared should any other IDs break the 53bit boundary.


3) Which fields will have String representations?
The fields which will have String representations are:

id (DM, Saved Search, User, List )
in_reply_to_status_id
in_reply_to_user_id
new_id (Streaming only. Will be removed when Snowflake is enabled)
current_user_retweet_id (When include_my_retweet=1 is passed)


4) Can you provide a complete Tweet example with Snowflake ID to test?

[{"coordinates":null,"truncated":false,"created_at":"Thu Oct 14 22:20:15
+
2010","favorited":false,"entities":{"urls":[],"hashtags":[],"user_mentions":[{"name":"Matt
Harris","id":777925,"id_str":"777925","indices":[0,14],"screen_name":"themattharris"}]},"text":"@themattharris
hey how are
things?","annotations":null,"contributors":[{"id":819797,"id_str":"819797","screen_name":"episod"}],"id":10765432100123456789,"id_str":"10765432100123456789","retweet_count":0,"geo":null,"retweeted":false,"in_reply_to_user_id":777925,"in_reply_to_user_id_str":"777925","in_reply_to_screen_name":"themattharris","user":{"id":6253282,"id_str":"6253282"},"source":"web","place":null,"in_reply_to_status_id":10586268426842688951,"in_reply_to_status_id_str":"10586268426842688951"}]


5) What is happening with new_id in the Streaming API?
new_id and new_id_str will be switched off when or soon after Snowflake is
enabled on November 4th.


6) Why not restrict IDs to 53bits?

A Snowflake ID is composed:
 * 41bits for millisecond precision time (69 years)
 * 10bits for a configured machine identity (1024 machines)
 * 12bits for a sequence number (4096 per machine)

The factor influencing the length of the ID is the time. For a 53bit ID this
would mean only 31bits are available for the time. 31bits is only enough for
24 days (2147483648/(1000*60*60*24)) of time.

Reducing the resolution of the timestamp would prevent a K-sorted resolution
of 1 second or less.

Reducing the configured machine identity or sequence number by 1bit would
mean we couldn’t scale Twitter, or operate our infrastructure in an
uncoordinated high-available way.


7) When will the 53bit Integer overflow happen?
24 days after Snowflake starts counting.


8) Is it safe to parse and store IDs as signed 64bit Integers?
Yes.


9) Why offer both the String and Integer versions of the ID?
The String representation is needed to ensure languages which cannot convert
the >53bit Integer can still use the ID in other API requests.

The Integer value is being retained for languages which can handle numbers
>53bit and to prevent applications which have not converted from being
cut-off from Twitter.


 10) When ID is null what will the _str representation be?
The _str representation will also be null.


11) Did you really mean ‘unsigned’ 64bit Integer?
Strictly speaking the Snowflake is a signed 64bit long under the hood. That
being said, we will never use the negative bit and won’t require the full
64bits for positive numbers for about 69 years:

http://www.google.com/search?q=%282**41%29+%2F+%2860*60*24*1000%29+%2F+365


12) Why not make the strings opt-in?
We did consider this as an option but decided against it for a number of
reasons. The first reason is that the ID is fundamental to being able to
work with the data from the API so receiving the correct ID shouldn’t be
something you have to opt into. The second, more influential reason, is that
making the _str representations opt-in would create significant, performance
affecting issues for the API.



On Mon, Oct 18, 2010 at 5:34 PM, themattharris wrote:

> Thanks to @gotwalt for spotting the missing commas.
>
> Fixed JSON sample ...
>
> [
>  {
>"coordinates": null,
>"truncated": false,
>"created_at": "Thu Oct 14 22:20

[twitter-dev] Requesting Whitelisting for Rate Limit

[Cassie Lynn]

Hello!

How often should you send a request to be whitelisted? I am finding
that in the span of time while I'm waiting for an answer, the nature
of my project has changed drastically. So I then resend a request.
Does this affect whether you will be whitelisted or not? And should I
wait for a rejection before rerequesting in the future?

Thank you,
- Cassie

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: How to test for one user following another

[Joe Rattz]

I am not doing it from the command line with Twurl.  I am doing it
from the Twurl Console that you provide and it doesn't work.

On Oct 7, 8:06 pm, Thomas Mango  wrote:
> I apologize, I was actually saying that you should specify both the
> source and the target. It was my understanding you needed both, but it
> looks like when you make an authenticated request (like you do with
> twurl), you can specify just the target.
>
> With that said, I was able to use twurl and specify only the target and
> get it to work:
>
> twurl "/friendships/show.xml?target_screen_name=Alternate1985"
>
> This used my authenticated user, @tsmango, as the source and gave me the
> proper response. Is that what your twurl call looked like?
>
> Also, if you don't quote the query, you'll have problems with multiple
> parameters:
>
> This one works:
> twurl
> "/friendships/show.xml?source_screen_name=samvermette&target_screen_name=Al­ternate1985"
>
> But this one fails with the error you were receiving:
> twurl
> /friendships/show.xml?source_screen_name=samvermette&target_screen_name=Alt­ernate1985
>
> Hope that helps and sorry again for the confusion about needed to
> specify the source.
>
>
>
>
>
> JoeRattzwrote:
> > That doesn't work either:
>
> > 
> >    /1/friendships/show.xml
> >    Target user not specified.
> > 
>
> > That's right from Twurl despite the fact that I provided both the
> > source_screen_name and target_screen_name.
>
> > Besides, why shouldn't the other two methods work?  They are
> > documented methods.
>
> > On Oct 7, 7:09 pm, Thomas Mango  wrote:
> >> You should be providing both the source and a target user to the
> >> /friendships/show method.
>
> >> You can use source_id&  target_id or source_screen_name&
> >> target_screen_name with /friendships/show.
>
> >> Here's the API 
> >> documentation:http://dev.twitter.com/doc/get/friendships/show
>
> >> JoeRattzwrote:
> >>> I would like to determine if my registered application's user is
> >>> following another user.
> >>> First I tried friendships/show with a target_screen_name = "someuser"
> >>> and get this error:
> >>> 
> >>>     /1/friendships/show.xml
> >>>     Target user not specified.
> >>> 
> >>> Then I tried friendships/show with user_a = "myusername" and user_b =
> >>> "someuser" and get this error:
> >>> 
> >>>     /1/friendships/exists.xml
> >>>     Two user ids or screen_names must be supplied.
> >>> 
> >>> I would prefer to use the show method and without having to specify my
> >>> application's user's username.
> >>> These are both using the Twulr Console.  What am I missing?
> >>> Thanks.
> >> --
> >> Thomas Mango
> >> tsma...@gmail.com- Hide quoted text -
>
> >> - Show quoted text -
>
> --
> Thomas Mango
> tsma...@gmail.com- Hide quoted text -
>
> - Show quoted text -

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Where to submit a bug report?

[Joe Rattz]

The statuses/friends method was specifically recommended to me to work
around the RateLimit problem I was having.  I don't know any other way
to get the statuses of approximately 60 users every minute when my app
is behind a firewall (preventing OAuth authentication for each
individual user).  So I use my app's access token/secret to get my
friends (and their most recent status).

I can't use the statuses/user_timeline because of basic auth going
away and OAuth requiring a callback to my server all due to rate
limiting and my inablity to get whitelisted.

Besides, what is the point of having an API method if it isn't
reliable (even when it successfully makes the call)?


On Oct 19, 3:55 pm, Taylor Singletary 
wrote:
> Hi Joe,
>
> This is likely a caching sync issue. You can report bugs 
> tohttp://code.google.com/p/twitter-api/issues/list
>
> I personally recommend avoiding statuses/friends as it's more of a legacy
> method than other means of discovering the same information. I personally
> recommend using friends/ids and users/lookup in conjunction with each other
> instead. While there's a best-effort to provide the most recent status in
> embedded user objects, the definitive means to determine this is by getting
> the most recent tweet from the user's statuses/user_timeline
>
> Taylor
>
>
>
> On Tue, Oct 19, 2010 at 12:41 PM, Joe Rattz  wrote:
> > How do I report a bug?
>
> > I am seeing what appears to be a bug right now and it is reproducbble
> > in the Twitter Twurl.
>
> > What I am seeing is a discrepancy in the latest status returned with
> > the statuses/friends web service call.  Basically, the XML interface
> > works properly but the JSON one does not.  I have a specific user that
> > is not returning the latest status for JSON (but does for XML).
>
> > I am hoping that someone could take a look at this quickly (yeah,
> > right) since it is reproducible.  I also suspect the issue may be
> > related to the fact that the user I am seeing this happen to is set to
> > private.  My user account is an approved follower though.  As I said,
> > the webservice works for XML, but not for JSON.
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk- Hide quoted text -
>
> - Show quoted text -

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] about xauth on a application

[paulo donizete gardinalli filho]

Hi,
recently i sent an email to a...@twitter.com with my app information. I
want to develope a application with speech enabled for visual deficient
to access twitter and other protocols, such as msn, googletalk.
My application name is chatvox. Is a...@twitter.com the correct e-mail? I
did not get answer from twitter staff to enable xauth for my app. It is
a desktop application.
can someone help me?
thanks in advance!
paulo

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Snowflake: An update and some very important information

[twittelator]

It's kind of cool that Craig has been programming professionally
longer than some people on this list have even been alive!

I've thought about the problem, and at least came up with a catchy
name for it to go with the crises of yore:  "Bitpocalypse".

Since Twittelator uses the JSON library YAJL, my approach will be to
correctly populate the "id" with an unsigned long long created from
the "id_str" field at the point of data arrival. Then it's done and no
other code needs changing. But I'll find out Friday!

On Oct 19, 12:27 pm, Craig Hockenberry 
wrote:
> This still gives you some API legacy that you need to maintain, but
> it's a much cleaner approach than what is currently being proposed.
>
> -ch
>
> On Oct 19, 10:39 am, Tom van der Woerdt  wrote:
>
>
>
> > I wouldn't blame this on JSON, because it's not JSON that has the
> > problems, but JavaScript. All of my Objective-C apps that communicate
> > use JSON as well, and they don't have the limitation. The issue does not
> > apply to XML either - there's no type specification in XML.
>
> > As far as I know, this issue will only cause trouble for a few
> > applications that work with JavaScript and depend on the IDs a lot.
>
> > My suggestion to solve this issue would be to introduce an additional
> > parameter (just like include_rts, just with a different name) that turns
> > all IDs into strings. No extra fields, just an additional optional
> > parameter. Won't cause trouble for the applications that can't parse it
> > and requires minimal implementation effort for developers.
>
> > I hope I'm not too late with my suggestion :-)
>
> > Tom
>
> > On 10/19/10 7:10 PM, Craig Hockenberry wrote:
>
> > > This approach feels wrong to me. The red flag is the duplication of
> > > data within the payload: in 30+ years of professional development,
> > > I've never seen that work out well.
>
> > > The root of the problem is that you've chosen to deliver data in a
> > > format (JSON) that can't support integers with a value greater than
> > > 2^53 bits. And some of your data uses 2^64 bits.
>
> > > The result is that you're working around the problem in a language by
> > > using a string. Avoiding the root problem will encumber you with
> > > legacy that you'll regret later.
>
> > > Look at your proposed solution from a different point-of-view: say you
> > > have a language that can't handle Unicode well (e.g. BASIC or Ruby.)
> > > Would you solve this problem by adding another field called
> > > "text_ascii"?
>
> > > "text": "@themattharris hey how are things in K benhavn?".
> > > "text_ascii": "@themattharris hey how are things in Kobenhavn?".
>
> > > Seems silly, yet that is exactly what you're doing for Javascript and
> > > long integers.
>
> > > A part of this legacy in your payload is future confusion for
> > > developers. Someone new to the Twitter API is going to be confused as
> > > to why your ID values have both numeric and string representations.
> > > And smart developers are going to lean towards the numeric
> > > representation:
>
> > > * 8 bytes of storage for 10765432100123456789 instead of 20 bytes.
> > > * Faster sorting (less data to compare.)
> > > * Correct sorting: "011" and "10" have different order depending on
> > > whether you're sorting the string or numeric representation.
>
> > > They'll eventually pay the price for choosing incorrectly.
>
> > > Every ID in the API is going to need documentation as a result. For
> > > example, are place IDs affected by this change? And what about the IDs
> > > returned by the Search API? (there's no mention of "since_id_str" and
> > > "max_id_str" above.)
>
> > > Losing consistency with the XML format is also a problem. Unless
> > > you're planning on adding _str elements to the XML payload, you're
> > > presenting developers with a one-way street. A consumer of JSON
> > > "id_str" can't  easily change the format of data they want to consume.
>
> > > In my mind, you really only have two good choices at this point:
>
> > > 1) Limit Snowflake's ID space to 2^53 bits. Easier for developers,
> > > harder for Twitter.
>
> > > 2) Make all Twitter IDs into strings. Easier for Twitter, harder for
> > > developers.
>
> > > The second choice is obviously more disruptive, but if you really need
> > > the ID space, it's the right one. Even if it means I need to make
> > > major changes to my code.
>
> > > On Oct 18, 5:19 pm, Matt Harris  wrote:
> > >> Last week you may remember Twitter planned to enable the new Status ID
> > >> generator - 'Snowflake' but didn't. The purpose of this email is to 
> > >> explain
> > >> the reason why this didn't happen, what we are doing about it, and what 
> > >> the
> > >> new release plan is.
>
> > >> So what is Snowflake?
> > >> --
> > >> Snowflake is a service we will be using to generate unique Tweet IDs. 
> > >> These
> > >> Tweet IDs are unique 64bit unsigned integers, which, instead of being
> > >> sequential like the current IDs, are based on tim

[twitter-dev] How to create and retrieve user with anywhere

[Matteo]

Hi to all,
I'm building an app where the user can login and signup through
twitter anywhere.

I created an web app and added the anywhere script to the page.If i
click the first time without being logged in in twitter i see the
login and then the allow/deny page.If i allow the app i'm redirected
to my home page with the connect button changed to connected with
twitter.

So far so good...
On the authComplete of the connectButton I create a user in my webapp
using oauth tokens and username.

Is there any api method to avoid the user to allow the application
each time she/he clicks on the connectButton?
Thanks a lot
Matteo

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Where to submit a bug report?

[Taylor Singletary]

Hi Joe,

This is likely a caching sync issue. You can report bugs to
http://code.google.com/p/twitter-api/issues/list

I personally recommend avoiding statuses/friends as it's more of a legacy
method than other means of discovering the same information. I personally
recommend using friends/ids and users/lookup in conjunction with each other
instead. While there's a best-effort to provide the most recent status in
embedded user objects, the definitive means to determine this is by getting
the most recent tweet from the user's statuses/user_timeline

Taylor

On Tue, Oct 19, 2010 at 12:41 PM, Joe Rattz  wrote:

> How do I report a bug?
>
> I am seeing what appears to be a bug right now and it is reproducbble
> in the Twitter Twurl.
>
> What I am seeing is a discrepancy in the latest status returned with
> the statuses/friends web service call.  Basically, the XML interface
> works properly but the JSON one does not.  I have a specific user that
> is not returning the latest status for JSON (but does for XML).
>
> I am hoping that someone could take a look at this quickly (yeah,
> right) since it is reproducible.  I also suspect the issue may be
> related to the fact that the user I am seeing this happen to is set to
> private.  My user account is an approved follower though.  As I said,
> the webservice works for XML, but not for JSON.
>
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk
>

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Where to submit a bug report?

[Joe Rattz]

How do I report a bug?

I am seeing what appears to be a bug right now and it is reproducbble
in the Twitter Twurl.

What I am seeing is a discrepancy in the latest status returned with
the statuses/friends web service call.  Basically, the XML interface
works properly but the JSON one does not.  I have a specific user that
is not returning the latest status for JSON (but does for XML).

I am hoping that someone could take a look at this quickly (yeah,
right) since it is reproducible.  I also suspect the issue may be
related to the fact that the user I am seeing this happen to is set to
private.  My user account is an approved follower though.  As I said,
the webservice works for XML, but not for JSON.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Snowflake: An update and some very important information

[Craig Hockenberry]

This still gives you some API legacy that you need to maintain, but
it's a much cleaner approach than what is currently being proposed.

-ch

On Oct 19, 10:39 am, Tom van der Woerdt  wrote:
> I wouldn't blame this on JSON, because it's not JSON that has the
> problems, but JavaScript. All of my Objective-C apps that communicate
> use JSON as well, and they don't have the limitation. The issue does not
> apply to XML either - there's no type specification in XML.
>
> As far as I know, this issue will only cause trouble for a few
> applications that work with JavaScript and depend on the IDs a lot.
>
> My suggestion to solve this issue would be to introduce an additional
> parameter (just like include_rts, just with a different name) that turns
> all IDs into strings. No extra fields, just an additional optional
> parameter. Won't cause trouble for the applications that can't parse it
> and requires minimal implementation effort for developers.
>
> I hope I'm not too late with my suggestion :-)
>
> Tom
>
> On 10/19/10 7:10 PM, Craig Hockenberry wrote:
>
>
>
> > This approach feels wrong to me. The red flag is the duplication of
> > data within the payload: in 30+ years of professional development,
> > I've never seen that work out well.
>
> > The root of the problem is that you've chosen to deliver data in a
> > format (JSON) that can't support integers with a value greater than
> > 2^53 bits. And some of your data uses 2^64 bits.
>
> > The result is that you're working around the problem in a language by
> > using a string. Avoiding the root problem will encumber you with
> > legacy that you'll regret later.
>
> > Look at your proposed solution from a different point-of-view: say you
> > have a language that can't handle Unicode well (e.g. BASIC or Ruby.)
> > Would you solve this problem by adding another field called
> > "text_ascii"?
>
> > "text": "@themattharris hey how are things in K benhavn?".
> > "text_ascii": "@themattharris hey how are things in Kobenhavn?".
>
> > Seems silly, yet that is exactly what you're doing for Javascript and
> > long integers.
>
> > A part of this legacy in your payload is future confusion for
> > developers. Someone new to the Twitter API is going to be confused as
> > to why your ID values have both numeric and string representations.
> > And smart developers are going to lean towards the numeric
> > representation:
>
> > * 8 bytes of storage for 10765432100123456789 instead of 20 bytes.
> > * Faster sorting (less data to compare.)
> > * Correct sorting: "011" and "10" have different order depending on
> > whether you're sorting the string or numeric representation.
>
> > They'll eventually pay the price for choosing incorrectly.
>
> > Every ID in the API is going to need documentation as a result. For
> > example, are place IDs affected by this change? And what about the IDs
> > returned by the Search API? (there's no mention of "since_id_str" and
> > "max_id_str" above.)
>
> > Losing consistency with the XML format is also a problem. Unless
> > you're planning on adding _str elements to the XML payload, you're
> > presenting developers with a one-way street. A consumer of JSON
> > "id_str" can't  easily change the format of data they want to consume.
>
> > In my mind, you really only have two good choices at this point:
>
> > 1) Limit Snowflake's ID space to 2^53 bits. Easier for developers,
> > harder for Twitter.
>
> > 2) Make all Twitter IDs into strings. Easier for Twitter, harder for
> > developers.
>
> > The second choice is obviously more disruptive, but if you really need
> > the ID space, it's the right one. Even if it means I need to make
> > major changes to my code.
>
> > On Oct 18, 5:19 pm, Matt Harris  wrote:
> >> Last week you may remember Twitter planned to enable the new Status ID
> >> generator - 'Snowflake' but didn't. The purpose of this email is to explain
> >> the reason why this didn't happen, what we are doing about it, and what the
> >> new release plan is.
>
> >> So what is Snowflake?
> >> --
> >> Snowflake is a service we will be using to generate unique Tweet IDs. These
> >> Tweet IDs are unique 64bit unsigned integers, which, instead of being
> >> sequential like the current IDs, are based on time. The full ID is composed
> >> of a timestamp, a worker number, and a sequence number.
>
> >> The problem
> >> -
> >> Before launch it came to our attention that some programming languages such
> >> as Javascript cannot support numbers with >53bits. This can be easily
> >> examined by running a command similar to: (90071992547409921).toString() in
> >> your browsers console or by running the following JSON snippet through your
> >> JSON parser.
>
> >>     {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>
> >> In affected JSON parsers the ID will not be converted successfully and will
> >> lose accuracy. In some parsers there may even be an exception.
>
> >> The solution
> >> 

Re: [twitter-dev] Re: Snowflake: An update and some very important information

[Tom van der Woerdt]

You normally don't need all 53 bits - but as snowflake simply skips a
few IDs every now and then, you get a lot more IDs.

Chance of it actually reaching 53 bits? I'd say that it happens at the
end of November... Friday the 26th?

Tom


On 10/19/10 8:04 PM, M. Edward (Ed) Borasky wrote:
> With all due respect, the root of the problem is that "computer
> scientists" think in terms of abstract machines with infinitely-wide
> registers, infinitely many addressable RAM cells, etc., and "business
> people" think in terms of human populations and their tweet rates
> growing geometrically for all time. Journalists believe neither of
> these. ;-) And neither assumption is realistic, which is why we have to
> make decisions like this from time to time, and why sometimes we predict
> disasters like Y2K or 32-bit machines crumbling in 2038 that don't
> actually happen. ;-)
> 
> So - for Twitter: what is your *realistic* projection for when a 53-bit
> integer ID will overflow? What are the underlying assumptions about
> human population growth, spread of Twitter, revenue models, competition,
> etc.? I know this is all highly confidential, so for sake of argument,
> assume current tweet rates per user and the goal your executives have
> stated of a billion users, with a plateau at that point. The question
> I'm asking is whether you *really* need 64-bit integer IDs for tweets or
> for users. ;-)
> 
> By the way, I ask similar questions of all the "big data" geeks out
> there - so many naked emperors, so little time. ;-)
> 

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Re: Snowflake: An update and some very important information

[M. Edward (Ed) Borasky]

With all due respect, the root of the problem is that "computer  
scientists" think in terms of abstract machines with infinitely-wide  
registers, infinitely many addressable RAM cells, etc., and "business  
people" think in terms of human populations and their tweet rates  
growing geometrically for all time. Journalists believe neither of  
these. ;-) And neither assumption is realistic, which is why we have  
to make decisions like this from time to time, and why sometimes we  
predict disasters like Y2K or 32-bit machines crumbling in 2038 that  
don't actually happen. ;-)


So - for Twitter: what is your *realistic* projection for when a  
53-bit integer ID will overflow? What are the underlying assumptions  
about human population growth, spread of Twitter, revenue models,  
competition, etc.? I know this is all highly confidential, so for sake  
of argument, assume current tweet rates per user and the goal your  
executives have stated of a billion users, with a plateau at that  
point. The question I'm asking is whether you *really* need 64-bit  
integer IDs for tweets or for users. ;-)


By the way, I ask similar questions of all the "big data" geeks out  
there - so many naked emperors, so little time. ;-)


--
M. Edward (Ed) Borasky
http://borasky-research.net http://twitter.com/znmeb

"A mathematician is a device for turning coffee into theorems." - Paul Erdos


Quoting Craig Hockenberry :


This approach feels wrong to me. The red flag is the duplication of
data within the payload: in 30+ years of professional development,
I've never seen that work out well.

The root of the problem is that you've chosen to deliver data in a
format (JSON) that can't support integers with a value greater than
2^53 bits. And some of your data uses 2^64 bits.

The result is that you're working around the problem in a language by
using a string. Avoiding the root problem will encumber you with
legacy that you'll regret later.

Look at your proposed solution from a different point-of-view: say you
have a language that can't handle Unicode well (e.g. BASIC or Ruby.)
Would you solve this problem by adding another field called
"text_ascii"?

"text": "@themattharris hey how are things in København?".
"text_ascii": "@themattharris hey how are things in Kobenhavn?".

Seems silly, yet that is exactly what you're doing for Javascript and
long integers.

A part of this legacy in your payload is future confusion for
developers. Someone new to the Twitter API is going to be confused as
to why your ID values have both numeric and string representations.
And smart developers are going to lean towards the numeric
representation:

* 8 bytes of storage for 10765432100123456789 instead of 20 bytes.
* Faster sorting (less data to compare.)
* Correct sorting: "011" and "10" have different order depending on
whether you're sorting the string or numeric representation.

They'll eventually pay the price for choosing incorrectly.

Every ID in the API is going to need documentation as a result. For
example, are place IDs affected by this change? And what about the IDs
returned by the Search API? (there's no mention of "since_id_str" and
"max_id_str" above.)

Losing consistency with the XML format is also a problem. Unless
you're planning on adding _str elements to the XML payload, you're
presenting developers with a one-way street. A consumer of JSON
"id_str" can't  easily change the format of data they want to consume.

In my mind, you really only have two good choices at this point:

1) Limit Snowflake's ID space to 2^53 bits. Easier for developers,
harder for Twitter.

2) Make all Twitter IDs into strings. Easier for Twitter, harder for
developers.

The second choice is obviously more disruptive, but if you really need
the ID space, it's the right one. Even if it means I need to make
major changes to my code.


On Oct 18, 5:19 pm, Matt Harris  wrote:

Last week you may remember Twitter planned to enable the new Status ID
generator - 'Snowflake' but didn't. The purpose of this email is to explain
the reason why this didn't happen, what we are doing about it, and what the
new release plan is.

So what is Snowflake?
--
Snowflake is a service we will be using to generate unique Tweet IDs. These
Tweet IDs are unique 64bit unsigned integers, which, instead of being
sequential like the current IDs, are based on time. The full ID is composed
of a timestamp, a worker number, and a sequence number.

The problem
-
Before launch it came to our attention that some programming languages such
as Javascript cannot support numbers with >53bits. This can be easily
examined by running a command similar to: (90071992547409921).toString() in
your browsers console or by running the following JSON snippet through your
JSON parser.

    {"id": 10765432100123456789, "id_str": "10765432100123456789"}

In affected JSON parsers the ID will not be converted successfully and will
lose accuracy. In some parsers there may 

[twitter-dev] Re: Change Background Image Not Working . Any help is appreciated

[x.charles.z]

Thanks a lot Matt. It worked. The two things I missed while trying to
upload the background image using your excellent library.

1) include filename={thefilename.jpg} element in the parameter array
2) add the 'use' => 'true' element in the parameter array.

Here is my final code

 $params = array(
'image' => 
"@{$img_path};type=image/jpeg;filename={$image}",
);

 $params['use'] = 'true';
 $tmhOAuth->request('POST', $tmhOAuth->url("account/
update_profile_background_image"), $params,
true, // use auth
true  // multipart
  );

On Oct 18, 6:54 pm, Matt Harris  wrote:
> There's an example in the tmhOAuth github project that has code for this:
>    http://github.com/themattharris/tmhOAuth/blob/master/examples/images.php
>
> The big difference for background images is remembering to send the filename
> as well.
> There have also been some users who have found that their version of curl
> required changing 'image' => to '@image'
>
> If neither of those work can you share the image that isn't working and
> we'll see what could be the problem.
>
> Best
> ---
> @themattharris
> Developer Advocate, Twitterhttp://twitter.com/themattharris
>
>
>
> On Mon, Oct 18, 2010 at 4:04 PM, x.charles.z  wrote:
> > I used the exact same code for the profile pic update except changing
> > the api function. The profile picture update works, but unfortunately
> > the background image update fails.
>
> >         $img_path = $_SERVER["DOCUMENT_ROOT"].'/images/twitter_bg/'.$image;
>
> >         require_once('./application/libraries/tmhOAuth.php');
>
> >          $oauth_tokens = $this->session->userdata('twitter_oauth_tokens');
> >          $tmhOAuth = new tmhOAuth(array(
> >            'consumer_key'    => T_CONSUMER_KEY,
> >            'consumer_secret' => T_CONSUMER_SECRET,
> >            'user_token'      => $oauth_tokens['access_token'],
> >            'user_secret'     => $oauth_tokens['access_token_secret']
> >         ));
>
> >          $img_post = array('image' => "@{$img_path};type=image/jpeg;");
>
> >         $tmhOAuth->request('POST', $tmhOAuth->url("account/
> > update_profile_background_image"), $img_post,
> >            true, // use auth
> >            true  // multipart
> >          );
>
> > The picture is jpg and only 40kb
>
> > The response I had:
>
> > (
> >           [date] => Mon, 18 Oct 2010 23:00:56 GMT
> >           [server] => hi
> >           [status] => 403 Forbidden
> >           [x_transaction] => 1287442856-44067-31467
>
> > [code] => 403
> >   [response] => {"error":"There was a problem with your background
> > image. Probably too big.","request":"/1/account/
> > update_profile_background_image.json"}
>
> > Thanks for taking a look.
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Remembering Authorization in Database

[Tom van der Woerdt]

Just save the OAuth Tokens. Simple as that :-)

Tom


On 10/19/10 5:26 PM, ATLChris wrote:
> Hello, I am developing a website (a.com) that will allow people to
> connect their existing account (on a.com) to their Twitter account. My
> site will use the Twitter API to scan peoples twitter friends looking
> for friends already on my site (a.com) and some status updates will
> occur. I am writing this in PHP.
> 
> What I am struggling with, is how I can save a users twitter
> information so the user doesn't have to be logged into Twitter.com
> each time my site needs to post a status update.
> 
> Like for example, Yelp.com I authorized Yelp.com to post to me feed,
> now when I rate a business, I can post that review to Twitter
> regardless of if they are logged into Twitter.com.
> 
> Or, like foursquare, when I checkin, I can tweet that checkin and it
> will show up on my feed whether I am logged into Twitter.com or not.
> 
> Are these sites saving my actual login credentials, or is there a way
> to save the oauth tokens in a database and just present them to the
> API when I need to post a tweet or get a list of that users twitter
> friends?
> 
> I hope this makes sense.
> 

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Re: Snowflake: An update and some very important information

[Tom van der Woerdt]

I wouldn't blame this on JSON, because it's not JSON that has the
problems, but JavaScript. All of my Objective-C apps that communicate
use JSON as well, and they don't have the limitation. The issue does not
apply to XML either - there's no type specification in XML.

As far as I know, this issue will only cause trouble for a few
applications that work with JavaScript and depend on the IDs a lot.

My suggestion to solve this issue would be to introduce an additional
parameter (just like include_rts, just with a different name) that turns
all IDs into strings. No extra fields, just an additional optional
parameter. Won't cause trouble for the applications that can't parse it
and requires minimal implementation effort for developers.

I hope I'm not too late with my suggestion :-)

Tom


On 10/19/10 7:10 PM, Craig Hockenberry wrote:
> This approach feels wrong to me. The red flag is the duplication of
> data within the payload: in 30+ years of professional development,
> I've never seen that work out well.
> 
> The root of the problem is that you've chosen to deliver data in a
> format (JSON) that can't support integers with a value greater than
> 2^53 bits. And some of your data uses 2^64 bits.
> 
> The result is that you're working around the problem in a language by
> using a string. Avoiding the root problem will encumber you with
> legacy that you'll regret later.
> 
> Look at your proposed solution from a different point-of-view: say you
> have a language that can't handle Unicode well (e.g. BASIC or Ruby.)
> Would you solve this problem by adding another field called
> "text_ascii"?
> 
> "text": "@themattharris hey how are things in København?".
> "text_ascii": "@themattharris hey how are things in Kobenhavn?".
> 
> Seems silly, yet that is exactly what you're doing for Javascript and
> long integers.
> 
> A part of this legacy in your payload is future confusion for
> developers. Someone new to the Twitter API is going to be confused as
> to why your ID values have both numeric and string representations.
> And smart developers are going to lean towards the numeric
> representation:
> 
> * 8 bytes of storage for 10765432100123456789 instead of 20 bytes.
> * Faster sorting (less data to compare.)
> * Correct sorting: "011" and "10" have different order depending on
> whether you're sorting the string or numeric representation.
> 
> They'll eventually pay the price for choosing incorrectly.
> 
> Every ID in the API is going to need documentation as a result. For
> example, are place IDs affected by this change? And what about the IDs
> returned by the Search API? (there's no mention of "since_id_str" and
> "max_id_str" above.)
> 
> Losing consistency with the XML format is also a problem. Unless
> you're planning on adding _str elements to the XML payload, you're
> presenting developers with a one-way street. A consumer of JSON
> "id_str" can't  easily change the format of data they want to consume.
> 
> In my mind, you really only have two good choices at this point:
> 
> 1) Limit Snowflake's ID space to 2^53 bits. Easier for developers,
> harder for Twitter.
> 
> 2) Make all Twitter IDs into strings. Easier for Twitter, harder for
> developers.
> 
> The second choice is obviously more disruptive, but if you really need
> the ID space, it's the right one. Even if it means I need to make
> major changes to my code.
> 
> 
> On Oct 18, 5:19 pm, Matt Harris  wrote:
>> Last week you may remember Twitter planned to enable the new Status ID
>> generator - 'Snowflake' but didn't. The purpose of this email is to explain
>> the reason why this didn't happen, what we are doing about it, and what the
>> new release plan is.
>>
>> So what is Snowflake?
>> --
>> Snowflake is a service we will be using to generate unique Tweet IDs. These
>> Tweet IDs are unique 64bit unsigned integers, which, instead of being
>> sequential like the current IDs, are based on time. The full ID is composed
>> of a timestamp, a worker number, and a sequence number.
>>
>> The problem
>> -
>> Before launch it came to our attention that some programming languages such
>> as Javascript cannot support numbers with >53bits. This can be easily
>> examined by running a command similar to: (90071992547409921).toString() in
>> your browsers console or by running the following JSON snippet through your
>> JSON parser.
>>
>> {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>>
>> In affected JSON parsers the ID will not be converted successfully and will
>> lose accuracy. In some parsers there may even be an exception.
>>
>> The solution
>> 
>> To allow javascript and JSON parsers to read the IDs we need to include a
>> string version of any ID when responding in the JSON format. What this means
>> is Status, User, Direct Message and Saved Search IDs in the Twitter API will
>> now be returned as an integer and a string in JSON responses. This will
>> apply to the main Twi

Re: [twitter-dev] Re: Snowflake: An update and some very important information

[Hayes Davis]

I did some investigation into the snowflake algorithm recently and yes, it's
safe for 64bit signed longs. Even if Twitter moved away from using
scala/java longs internally (which are definitely signed), you'd still have
something like 65 years from now before the algorithm rolled past the 2^63-1
barrier.

I've posted a a gist[1] in ruby with a few little methods for playing with
the time part of a snowflake id if you're interested.

Hayes

1 http://gist.github.com/634586

On Tue, Oct 19, 2010 at 6:27 AM, Dan Checkoway  wrote:

> I'm also patiently awaiting a response from twitter about this.  Are the
> ids sane for 64-bit *signed* long?
>
> Dan
>
>
> On Mon, Oct 18, 2010 at 9:08 PM, jon  wrote:
>
>> Hi,
>>
>> You wrote that the IDs are "unsigned" 64 bit ints, but the IdWorker is
>> pumping out java Longs which are signed.  I'm assuming that was a
>> typo, but please clarify.
>>
>>
>> http://github.com/twitter/snowflake/blob/master/src/main/scala/com/twitter/service/snowflake/IdWorker.scala
>>
>> Thanks,
>>
>> - Jon
>>
>> On Oct 18, 8:19 pm, Matt Harris  wrote:
>> > Last week you may remember Twitter planned to enable the new Status ID
>> > generator - 'Snowflake' but didn't. The purpose of this email is to
>> explain
>> > the reason why this didn't happen, what we are doing about it, and what
>> the
>> > new release plan is.
>> >
>> > So what is Snowflake?
>> > --
>> > Snowflake is a service we will be using to generate unique Tweet IDs.
>> These
>> > Tweet IDs are unique 64bit unsigned integers, which, instead of being
>> > sequential like the current IDs, are based on time. The full ID is
>> composed
>> > of a timestamp, a worker number, and a sequence number.
>> >
>> > The problem
>> > -
>> > Before launch it came to our attention that some programming languages
>> such
>> > as Javascript cannot support numbers with >53bits. This can be easily
>> > examined by running a command similar to: (90071992547409921).toString()
>> in
>> > your browsers console or by running the following JSON snippet through
>> your
>> > JSON parser.
>> >
>> > {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>> >
>> > In affected JSON parsers the ID will not be converted successfully and
>> will
>> > lose accuracy. In some parsers there may even be an exception.
>> >
>> > The solution
>> > 
>> > To allow javascript and JSON parsers to read the IDs we need to include
>> a
>> > string version of any ID when responding in the JSON format. What this
>> means
>> > is Status, User, Direct Message and Saved Search IDs in the Twitter API
>> will
>> > now be returned as an integer and a string in JSON responses. This will
>> > apply to the main Twitter API, the Streaming API and the Search API.
>> >
>> > For example, a status object will now contain an id and an id_str. The
>> > following JSON representation of a status object shows the two versions
>> of
>> > the ID fields for each data point.
>> >
>> > [
>> >   {
>> > "coordinates": null,
>> > "truncated": false,
>> > "created_at": "Thu Oct 14 22:20:15 + 2010",
>> > "favorited": false,
>> > "entities": {
>> >   "urls": [
>> >   ],
>> >   "hashtags": [
>> >   ],
>> >   "user_mentions": [
>> > {
>> >   "name": "Matt Harris",
>> >   "id": 777925,
>> >   "id_str": "777925",
>> >   "indices": [
>> > 0,
>> > 14
>> >   ],
>> >   "screen_name": "themattharris"
>> > }
>> >   ]
>> > },
>> > "text": "@themattharris hey how are things?",
>> > "annotations": null,
>> > "contributors": [
>> >   {
>> > "id": 819797,
>> > "id_str": "819797",
>> > "screen_name": "episod"
>> >   }
>> > ],
>> > "id": 12738165059,
>> > "id_str": "12738165059",
>> > "retweet_count": 0,
>> > "geo": null,
>> > "retweeted": false,
>> > "in_reply_to_user_id": 777925,
>> > "in_reply_to_user_id_str": "777925",
>> > "in_reply_to_screen_name": "themattharris",
>> > "user": {
>> >   "id": 6253282
>> >   "id_str": "6253282"
>> > },
>> > "source": "web",
>> > "place": null,
>> > "in_reply_to_status_id": 12738040524
>> > "in_reply_to_status_id_str": "12738040524"
>> >   }
>> > ]
>> >
>> > What should you do - RIGHT NOW
>> > --
>> > The first thing you should do is attempt to decode the JSON snippet
>> above
>> > using your production code parser. Observe the output to confirm the ID
>> has
>> > not lost accuracy.
>> >
>> > What you do next depends on what happens:
>> >
>> > * If your code converts the ID successfully without losing accuracy you
>> are
>> > OK but should consider converting to the _str versions of IDs as soon as
>> > possible.
>> > * If your code has lost accuracy, convert your code to using the _str
>> > version immediately. If you do not do this you

[twitter-dev] Re: Snowflake: An update and some very important information

[Craig Hockenberry]

This approach feels wrong to me. The red flag is the duplication of
data within the payload: in 30+ years of professional development,
I've never seen that work out well.

The root of the problem is that you've chosen to deliver data in a
format (JSON) that can't support integers with a value greater than
2^53 bits. And some of your data uses 2^64 bits.

The result is that you're working around the problem in a language by
using a string. Avoiding the root problem will encumber you with
legacy that you'll regret later.

Look at your proposed solution from a different point-of-view: say you
have a language that can't handle Unicode well (e.g. BASIC or Ruby.)
Would you solve this problem by adding another field called
"text_ascii"?

"text": "@themattharris hey how are things in København?".
"text_ascii": "@themattharris hey how are things in Kobenhavn?".

Seems silly, yet that is exactly what you're doing for Javascript and
long integers.

A part of this legacy in your payload is future confusion for
developers. Someone new to the Twitter API is going to be confused as
to why your ID values have both numeric and string representations.
And smart developers are going to lean towards the numeric
representation:

* 8 bytes of storage for 10765432100123456789 instead of 20 bytes.
* Faster sorting (less data to compare.)
* Correct sorting: "011" and "10" have different order depending on
whether you're sorting the string or numeric representation.

They'll eventually pay the price for choosing incorrectly.

Every ID in the API is going to need documentation as a result. For
example, are place IDs affected by this change? And what about the IDs
returned by the Search API? (there's no mention of "since_id_str" and
"max_id_str" above.)

Losing consistency with the XML format is also a problem. Unless
you're planning on adding _str elements to the XML payload, you're
presenting developers with a one-way street. A consumer of JSON
"id_str" can't  easily change the format of data they want to consume.

In my mind, you really only have two good choices at this point:

1) Limit Snowflake's ID space to 2^53 bits. Easier for developers,
harder for Twitter.

2) Make all Twitter IDs into strings. Easier for Twitter, harder for
developers.

The second choice is obviously more disruptive, but if you really need
the ID space, it's the right one. Even if it means I need to make
major changes to my code.


On Oct 18, 5:19 pm, Matt Harris  wrote:
> Last week you may remember Twitter planned to enable the new Status ID
> generator - 'Snowflake' but didn't. The purpose of this email is to explain
> the reason why this didn't happen, what we are doing about it, and what the
> new release plan is.
>
> So what is Snowflake?
> --
> Snowflake is a service we will be using to generate unique Tweet IDs. These
> Tweet IDs are unique 64bit unsigned integers, which, instead of being
> sequential like the current IDs, are based on time. The full ID is composed
> of a timestamp, a worker number, and a sequence number.
>
> The problem
> -
> Before launch it came to our attention that some programming languages such
> as Javascript cannot support numbers with >53bits. This can be easily
> examined by running a command similar to: (90071992547409921).toString() in
> your browsers console or by running the following JSON snippet through your
> JSON parser.
>
>     {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>
> In affected JSON parsers the ID will not be converted successfully and will
> lose accuracy. In some parsers there may even be an exception.
>
> The solution
> 
> To allow javascript and JSON parsers to read the IDs we need to include a
> string version of any ID when responding in the JSON format. What this means
> is Status, User, Direct Message and Saved Search IDs in the Twitter API will
> now be returned as an integer and a string in JSON responses. This will
> apply to the main Twitter API, the Streaming API and the Search API.
>
> For example, a status object will now contain an id and an id_str. The
> following JSON representation of a status object shows the two versions of
> the ID fields for each data point.
>
> [
>   {
>     "coordinates": null,
>     "truncated": false,
>     "created_at": "Thu Oct 14 22:20:15 + 2010",
>     "favorited": false,
>     "entities": {
>       "urls": [
>       ],
>       "hashtags": [
>       ],
>       "user_mentions": [
>         {
>           "name": "Matt Harris",
>           "id": 777925,
>           "id_str": "777925",
>           "indices": [
>             0,
>             14
>           ],
>           "screen_name": "themattharris"
>         }
>       ]
>     },
>     "text": "@themattharris hey how are things?",
>     "annotations": null,
>     "contributors": [
>       {
>         "id": 819797,
>         "id_str": "819797",
>         "screen_name": "episod"
>       }
>     ],
>     "id": 12738165059,
>     "

[twitter-dev] Site Streams API + Ouath in Python

[Ethan]

Has anyone implemented the Site Streams beta in Python using the oauth
authentication? All examples I've seen rely on plain auth, not oauth,
and tweepy doesn't work for oauth for Streaming.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Re: Snowflake: An update and some very important information

[Brion Vibber]

Java doesn't have unsigned types, so a (signed) long is the only way to
transfer the value.

IIRC from peeking at that code, the top bit is unused, which would mean
there's no danger of creating an id value that's ambiguous. Storing and
comparing ids in signed or unsigned 64-bit longs should be fine.

-- brion vibber (brion @ status.net)
On Oct 19, 2010 5:52 AM, "jon"  wrote:
> Hi,
>
> You wrote that the IDs are "unsigned" 64 bit ints, but the IdWorker is
> pumping out java Longs which are signed. I'm assuming that was a
> typo, but please clarify.
>
>
http://github.com/twitter/snowflake/blob/master/src/main/scala/com/twitter/service/snowflake/IdWorker.scala
>
> Thanks,
>
> - Jon
>
> On Oct 18, 8:19 pm, Matt Harris  wrote:
>> Last week you may remember Twitter planned to enable the new Status ID
>> generator - 'Snowflake' but didn't. The purpose of this email is to
explain
>> the reason why this didn't happen, what we are doing about it, and what
the
>> new release plan is.
>>
>> So what is Snowflake?
>> --
>> Snowflake is a service we will be using to generate unique Tweet IDs.
These
>> Tweet IDs are unique 64bit unsigned integers, which, instead of being
>> sequential like the current IDs, are based on time. The full ID is
composed
>> of a timestamp, a worker number, and a sequence number.
>>
>> The problem
>> -
>> Before launch it came to our attention that some programming languages
such
>> as Javascript cannot support numbers with >53bits. This can be easily
>> examined by running a command similar to: (90071992547409921).toString()
in
>> your browsers console or by running the following JSON snippet through
your
>> JSON parser.
>>
>> {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>>
>> In affected JSON parsers the ID will not be converted successfully and
will
>> lose accuracy. In some parsers there may even be an exception.
>>
>> The solution
>> 
>> To allow javascript and JSON parsers to read the IDs we need to include a
>> string version of any ID when responding in the JSON format. What this
means
>> is Status, User, Direct Message and Saved Search IDs in the Twitter API
will
>> now be returned as an integer and a string in JSON responses. This will
>> apply to the main Twitter API, the Streaming API and the Search API.
>>
>> For example, a status object will now contain an id and an id_str. The
>> following JSON representation of a status object shows the two versions
of
>> the ID fields for each data point.
>>
>> [
>>   {
>> "coordinates": null,
>> "truncated": false,
>> "created_at": "Thu Oct 14 22:20:15 + 2010",
>> "favorited": false,
>> "entities": {
>>   "urls": [
>>   ],
>>   "hashtags": [
>>   ],
>>   "user_mentions": [
>> {
>>   "name": "Matt Harris",
>>   "id": 777925,
>>   "id_str": "777925",
>>   "indices": [
>> 0,
>> 14
>>   ],
>>   "screen_name": "themattharris"
>> }
>>   ]
>> },
>> "text": "@themattharris hey how are things?",
>> "annotations": null,
>> "contributors": [
>>   {
>> "id": 819797,
>> "id_str": "819797",
>> "screen_name": "episod"
>>   }
>> ],
>> "id": 12738165059,
>> "id_str": "12738165059",
>> "retweet_count": 0,
>> "geo": null,
>> "retweeted": false,
>> "in_reply_to_user_id": 777925,
>> "in_reply_to_user_id_str": "777925",
>> "in_reply_to_screen_name": "themattharris",
>> "user": {
>>   "id": 6253282
>>   "id_str": "6253282"
>> },
>> "source": "web",
>> "place": null,
>> "in_reply_to_status_id": 12738040524
>> "in_reply_to_status_id_str": "12738040524"
>>   }
>> ]
>>
>> What should you do - RIGHT NOW
>> --
>> The first thing you should do is attempt to decode the JSON snippet above
>> using your production code parser. Observe the output to confirm the ID
has
>> not lost accuracy.
>>
>> What you do next depends on what happens:
>>
>> * If your code converts the ID successfully without losing accuracy you
are
>> OK but should consider converting to the _str versions of IDs as soon as
>> possible.
>> * If your code has lost accuracy, convert your code to using the _str
>> version immediately. If you do not do this your code will be unable to
>> interact with the Twitter API reliably.
>> * In some language parsers, the JSON may throw an exception when reading
the
>> ID value. If this happens in your parser you will need to ‘pre-parse’ the
>> data, removing or replacing ID parameters with their _str versions.
>>
>> Summary
>> -
>> 1) If you develop in Javascript, know that you will have to update your
code
>> to read the string version instead of the integer version.
>>
>> 2) If you use a JSON decoder, validate that the example JSON, above,
decodes
>> without throwing exceptions. If except

[twitter-dev] Remembering Authorization in Database

[ATLChris]

Hello, I am developing a website (a.com) that will allow people to
connect their existing account (on a.com) to their Twitter account. My
site will use the Twitter API to scan peoples twitter friends looking
for friends already on my site (a.com) and some status updates will
occur. I am writing this in PHP.

What I am struggling with, is how I can save a users twitter
information so the user doesn't have to be logged into Twitter.com
each time my site needs to post a status update.

Like for example, Yelp.com I authorized Yelp.com to post to me feed,
now when I rate a business, I can post that review to Twitter
regardless of if they are logged into Twitter.com.

Or, like foursquare, when I checkin, I can tweet that checkin and it
will show up on my feed whether I am logged into Twitter.com or not.

Are these sites saving my actual login credentials, or is there a way
to save the oauth tokens in a database and just present them to the
API when I need to post a tweet or get a list of that users twitter
friends?

I hope this makes sense.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Re: [twitcurl Lib] Direct Message signbase string

[Matt Harris]

You should also update the hostname to as you are using the wrong one. The API 
should be accesses through:
http://api.twitter.com/1

Making your request:
http://api.twitter.com/1/direct_messages/new.xml

Best,
@themattharris

On Oct 19, 2010, at 6:05, Tom van der Woerdt  wrote:

> Yes, you should.
> 
> An easy way to test your Base String is to paste it into the validation
> box at
> .
> 
> Tom
> 
> 
> On 10/19/10 2:03 PM, balbari wrote:
>> at the end of URL part should I remove a '?' ?
>> 
>> BAD ==> POST&http%3A%2F%2Ftwitter.com%2Fdirect_messages%2Fnew.xml%3F
>> GOOD ==> POST&http%3A%2F%2Ftwitter.com%2Fdirect_messages%2Fnew.xml
>> 
>> GOOD case right?
>> 
>> 
>> On 10월19일, 오후5시15분, Tom van der Woerdt  wrote:
>>> Looks like there's a '?' in the URL part. Shouldn't be there.
>>> 
>>> Tom
>>> 
>>> On Oct 19, 2010, at 7:24 AM, balbari  wrote:
>>> 
>>> 
>>> 
 I'm using twitcurl library.
>>> 
 When you send a direct message an error occurs.
>>> 
 Error Message : Incorrect signature
>>> 
 When I send a message signbase string is shown below.
>>> 
 POST&http%3A%2F%2Ftwitter.com%2Fdirect_messages%2Fnew.xml%3F
 screen_name%3DRECEIVERNM&
 oauth_consumer_key%3DCKEY%26
 oauth_nonce%3D1287392764ed%26
 oauth_signature_method%3DHMAC-SHA1%26
 oauth_timestamp%3D1287392764%26
 oauth_token%3DATOKEN%26
 oauth_version%3D1.0%26
 text%3D12345"
>>> 
 See you on the signbase wrong ones?
 If you know something is wrong, please correct parts.
>>> 
 --
 Twitter developer documentation and resources:http://dev.twitter.com/doc
 API updates via Twitter:http://twitter.com/twitterapi
 Issues/Enhancements 
 Tracker:http://code.google.com/p/twitter-api/issues/list
 Change your membership to this 
 group:http://groups.google.com/group/twitter-development-talk- 원본 텍스트 숨기기 -
>>> 
>>> - 원본 텍스트 보기 -
>> 
> 
> -- 
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group: 
> http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Cross-domain policy file

[zeh fernando]

Thanks for the support Orian. I really want to understand why Twitter
is blocking that kind of cross-domain requests, as I believe it just
makes things more difficult, without really blocking what one would
consider a "security issue".

On Oct 19, 3:10 am, "Orian Marx (@orian)"  wrote:
> Zeh, thanks for taking the time to bring this issue to light again and
> to present so many examples of other significant APIs that do not have
> restrictive crossdomain policies. As you note, this issue has been
> brought to Twitter's attention several times over the last few years
> but to no avail.
>
> For my work I continue to have to rely on a PHP proxy for all calls
> between my Flash client and Twitter. This is certainly not ideal.
>
> Team Twitter, it's time for you to address this issue. One of the most
> popular clients for Twitter out there, TweetDeck, is built with Flash
> technology and yet runs as an AIR app I'm guessing in part because
> that has a different security model and does not have to deal with
> this. You should recognize that there is a large pool of developer
> talent that has, over the years, attempted to build wonderful things
> on your platform but have thrown up their hands and left due to
> frustration with this crossdomain policy. Please stop treating us as
> second class developers.
>
> Thanks,
> Orian
>
> On Oct 18, 3:34 pm, zeh fernando  wrote:
>
> > Does Twitter have any plans on when/whether they'll change its current
> > cross-domain policy file?
>
> >http://api.twitter.com/crossdomain.xmldoesnot allow requests from
> > Flash-based websites and web apps because it restricts response to
> > twitter.com subdomains.
>
> >http://search.twitter.com/crossdomain.xml, however, does allow Flash
> > requests from any domain.
>
> > This policy pretty much renders all Flash calls to the API useless
> > (unless they're search calls).
>
> > One could use proxy scripts, but given the limitations imposed by the
> > Twitter API (150 calls per IP per hour), it means public websites are
> > out of luck if they're getting any kind of public data without
> > authenticating like, say, getting a (public) user timeline.
>
> > This has been discussed at length in previous threads.
>
> > Change in 
> > crossdomain.xml??http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> > Most curiously, the above thread mentions on March 2008 that Twitter
> > would be moving API calls to api.twitter.com and allowing a more
> > permissive crossdomain policy file there in a few months. This hasn't
> > happened, though, since people have continued to be dumbfounded by the
> > inability to load Twitter data from Flash-based web apps.
>
> > Twitter Stream 
> > crossdomain.xmlhttp://groups.google.com/group/twitter-development-talk/browse_thread...
>
> > I think this decision is specially questionable as the cross-domain
> > restrictions in place do nothing else other than put a tax on what
> > people can do from Flash-based web apps, but also allow any other
> > usage from any other technology, be it a security issue or not. In
> > fact, even using PHP proxies one could make the API calls from Flash
> > (albeit in a restricted manner) so I can't see a real reason for
> > singling out/blocking this platform.
>
> > Normally, public APIs add no such artificial/ineffective restrictions,
> > and simply allow any kind of connection (doing their own top of their
> > own built-in restrictions and rate limiting)...
>
> >http://graph.facebook.com/crossdomain.xml-allows connections from
> > all domainshttp://api.flickr.com/crossdomain.xml-allows connections from all
> > domainshttp://api.plixi.com/crossdomain.xml-allows connections from all
> > domainshttp://api.bit.ly/crossdomain.xml-allows connections from all
> > domainshttp://stream.twitvid.com/crossdomain.xml-allows connections from
> > all domains
> > ...etc etc
>
> > So, is there any clear reason why the restriction is still in place?
> > Or any idea on when this policy will be reviewed?
>
> > Thanks,
> > Zeh

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Maximum username length

[Taylor Singletary]

15 characters is the current limit. 20 was at one time the limit.

All numbers is allowed.
Spaces are not allowed.

This regular expression should help you validate: /\A[a-zA-Z0-9_]*\z/

Taylor

On Mon, Oct 18, 2010 at 6:19 PM, Gonzalo Larralde  wrote:

> On Thu, Mar 11, 2010 at 7:12 AM, Nick Telford
>  wrote:
> > Hi everyone,
> >
> > Can we get a clarification on the maximum length of a username? The
> > twitter.com frontend refuses to accept anything over 15 characters,
> > and I'm fairly sure 15 characters is mentioned elsewhere in some
> > documentation.
> >
> > However, we're seeing an increasing number of users who have (somehow)
> > managed to register with a longer username:
> >
> > http://twitter.com/toasteroverheated
> > http://twitter.com/veganstraightedge
> > http://twitter.com/Laura_Villas_Boas
> > http://twitter.com/colepatrickturner
> >
> > The number of user's that have managed to generate usernames over 15
> > characters in length is increasing, although not by a lot. It wouldn't
> > surprise me if there are < 100 users affected.
> >
> > A clarification on the absolute limit would be useful for us to
> > determine how best to optimise our storage of usernames.
>
> I think it's really important get an specific definition on which
> usernames we may expect historically, and what's the actual username
> criteria.
>
> Can any twitter dev explain how we may validate usernames and what's
> the best way to store them into a db?
>
> Thanks!
>
> --
> Slds,
>
> Gonzalo.
>
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk
>

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Re: Snowflake: An update and some very important information

[Dan Checkoway]

I'm also patiently awaiting a response from twitter about this.  Are the ids
sane for 64-bit *signed* long?

Dan

On Mon, Oct 18, 2010 at 9:08 PM, jon  wrote:

> Hi,
>
> You wrote that the IDs are "unsigned" 64 bit ints, but the IdWorker is
> pumping out java Longs which are signed.  I'm assuming that was a
> typo, but please clarify.
>
>
> http://github.com/twitter/snowflake/blob/master/src/main/scala/com/twitter/service/snowflake/IdWorker.scala
>
> Thanks,
>
> - Jon
>
> On Oct 18, 8:19 pm, Matt Harris  wrote:
> > Last week you may remember Twitter planned to enable the new Status ID
> > generator - 'Snowflake' but didn't. The purpose of this email is to
> explain
> > the reason why this didn't happen, what we are doing about it, and what
> the
> > new release plan is.
> >
> > So what is Snowflake?
> > --
> > Snowflake is a service we will be using to generate unique Tweet IDs.
> These
> > Tweet IDs are unique 64bit unsigned integers, which, instead of being
> > sequential like the current IDs, are based on time. The full ID is
> composed
> > of a timestamp, a worker number, and a sequence number.
> >
> > The problem
> > -
> > Before launch it came to our attention that some programming languages
> such
> > as Javascript cannot support numbers with >53bits. This can be easily
> > examined by running a command similar to: (90071992547409921).toString()
> in
> > your browsers console or by running the following JSON snippet through
> your
> > JSON parser.
> >
> > {"id": 10765432100123456789, "id_str": "10765432100123456789"}
> >
> > In affected JSON parsers the ID will not be converted successfully and
> will
> > lose accuracy. In some parsers there may even be an exception.
> >
> > The solution
> > 
> > To allow javascript and JSON parsers to read the IDs we need to include a
> > string version of any ID when responding in the JSON format. What this
> means
> > is Status, User, Direct Message and Saved Search IDs in the Twitter API
> will
> > now be returned as an integer and a string in JSON responses. This will
> > apply to the main Twitter API, the Streaming API and the Search API.
> >
> > For example, a status object will now contain an id and an id_str. The
> > following JSON representation of a status object shows the two versions
> of
> > the ID fields for each data point.
> >
> > [
> >   {
> > "coordinates": null,
> > "truncated": false,
> > "created_at": "Thu Oct 14 22:20:15 + 2010",
> > "favorited": false,
> > "entities": {
> >   "urls": [
> >   ],
> >   "hashtags": [
> >   ],
> >   "user_mentions": [
> > {
> >   "name": "Matt Harris",
> >   "id": 777925,
> >   "id_str": "777925",
> >   "indices": [
> > 0,
> > 14
> >   ],
> >   "screen_name": "themattharris"
> > }
> >   ]
> > },
> > "text": "@themattharris hey how are things?",
> > "annotations": null,
> > "contributors": [
> >   {
> > "id": 819797,
> > "id_str": "819797",
> > "screen_name": "episod"
> >   }
> > ],
> > "id": 12738165059,
> > "id_str": "12738165059",
> > "retweet_count": 0,
> > "geo": null,
> > "retweeted": false,
> > "in_reply_to_user_id": 777925,
> > "in_reply_to_user_id_str": "777925",
> > "in_reply_to_screen_name": "themattharris",
> > "user": {
> >   "id": 6253282
> >   "id_str": "6253282"
> > },
> > "source": "web",
> > "place": null,
> > "in_reply_to_status_id": 12738040524
> > "in_reply_to_status_id_str": "12738040524"
> >   }
> > ]
> >
> > What should you do - RIGHT NOW
> > --
> > The first thing you should do is attempt to decode the JSON snippet above
> > using your production code parser. Observe the output to confirm the ID
> has
> > not lost accuracy.
> >
> > What you do next depends on what happens:
> >
> > * If your code converts the ID successfully without losing accuracy you
> are
> > OK but should consider converting to the _str versions of IDs as soon as
> > possible.
> > * If your code has lost accuracy, convert your code to using the _str
> > version immediately. If you do not do this your code will be unable to
> > interact with the Twitter API reliably.
> > * In some language parsers, the JSON may throw an exception when reading
> the
> > ID value. If this happens in your parser you will need to ‘pre-parse’ the
> > data, removing or replacing ID parameters with their _str versions.
> >
> > Summary
> > -
> > 1) If you develop in Javascript, know that you will have to update your
> code
> > to read the string version instead of the integer version.
> >
> > 2) If you use a JSON decoder, validate that the example JSON, above,
> decodes
> > without throwing exceptions. If exceptions are thrown, you will need to
> > pre-parse the data. Please let u

Re: [twitter-dev] Re: [twitcurl Lib] Direct Message signbase string

[Tom van der Woerdt]

Yes, you should.

An easy way to test your Base String is to paste it into the validation
box at
.

Tom


On 10/19/10 2:03 PM, balbari wrote:
> at the end of URL part should I remove a '?' ?
> 
> BAD ==> POST&http%3A%2F%2Ftwitter.com%2Fdirect_messages%2Fnew.xml%3F
> GOOD ==> POST&http%3A%2F%2Ftwitter.com%2Fdirect_messages%2Fnew.xml
> 
> GOOD case right?
> 
> 
> On 10월19일, 오후5시15분, Tom van der Woerdt  wrote:
>> Looks like there's a '?' in the URL part. Shouldn't be there.
>>
>> Tom
>>
>> On Oct 19, 2010, at 7:24 AM, balbari  wrote:
>>
>>
>>
>>> I'm using twitcurl library.
>>
>>> When you send a direct message an error occurs.
>>
>>> Error Message : Incorrect signature
>>
>>> When I send a message signbase string is shown below.
>>
>>> POST&http%3A%2F%2Ftwitter.com%2Fdirect_messages%2Fnew.xml%3F
>>> screen_name%3DRECEIVERNM&
>>> oauth_consumer_key%3DCKEY%26
>>> oauth_nonce%3D1287392764ed%26
>>> oauth_signature_method%3DHMAC-SHA1%26
>>> oauth_timestamp%3D1287392764%26
>>> oauth_token%3DATOKEN%26
>>> oauth_version%3D1.0%26
>>> text%3D12345"
>>
>>> See you on the signbase wrong ones?
>>> If you know something is wrong, please correct parts.
>>
>>> --
>>> Twitter developer documentation and resources:http://dev.twitter.com/doc
>>> API updates via Twitter:http://twitter.com/twitterapi
>>> Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list
>>> Change your membership to this 
>>> group:http://groups.google.com/group/twitter-development-talk- 원본 텍스트 숨기기 -
>>
>> - 원본 텍스트 보기 -
> 

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] Re: Snowflake: An update and some very important information

[Tom van der Woerdt]

Probably null as well.

Tom


On 10/19/10 11:49 AM, Reivax wrote:
> Hi
> 
> In the case where an id is null (as in "in_reply_to_status_id":null )
> what will the value of "in_reply_to_status_id_str" be ?
> 
> Thanks
> Xavier
> 
> On 19 oct, 02:34, themattharris  wrote:
>> Thanks to @gotwalt for spotting the missing commas.
>>
>> Fixed JSON sample ...
>>
>> [
>>   {
>> "coordinates": null,
>> "truncated": false,
>> "created_at": "Thu Oct 14 22:20:15 + 2010",
>> "favorited": false,
>> "entities": {
>>   "urls": [
>>   ],
>>   "hashtags": [
>>   ],
>>   "user_mentions": [
>> {
>>   "name": "Matt Harris",
>>   "id": 777925,
>>   "id_str": "777925",
>>   "indices": [
>> 0,
>> 14
>>   ],
>>   "screen_name": "themattharris"
>> }
>>   ]
>> },
>> "text": "@themattharris hey how are things?",
>> "annotations": null,
>> "contributors": [
>>   {
>> "id": 819797,
>> "id_str": "819797",
>> "screen_name": "episod"
>>   }
>> ],
>> "id": 12738165059,
>> "id_str": "12738165059",
>> "retweet_count": 0,
>> "geo": null,
>> "retweeted": false,
>> "in_reply_to_user_id": 777925,
>> "in_reply_to_user_id_str": "777925",
>> "in_reply_to_screen_name": "themattharris",
>> "user": {
>>   "id": 6253282,
>>   "id_str": "6253282"
>> },
>> "source": "web",
>> "place": null,
>> "in_reply_to_status_id": 12738040524,
>> "in_reply_to_status_id_str": "12738040524"
>>   }
>> ]
>>
>> Best,
>> @themattharris
>>
>> On Oct 18, 5:19 pm, Matt Harris  wrote:
>>
>>> Last week you may remember Twitter planned to enable the new Status ID
>>> generator - 'Snowflake' but didn't. The purpose of this email is to explain
>>> the reason why this didn't happen, what we are doing about it, and what the
>>> new release plan is.
>>
>>> So what is Snowflake?
>>> --
>>> Snowflake is a service we will be using to generate unique Tweet IDs. These
>>> Tweet IDs are unique 64bit unsigned integers, which, instead of being
>>> sequential like the current IDs, are based on time. The full ID is composed
>>> of a timestamp, a worker number, and a sequence number.
>>
>>> The problem
>>> -
>>> Before launch it came to our attention that some programming languages such
>>> as Javascript cannot support numbers with >53bits. This can be easily
>>> examined by running a command similar to: (90071992547409921).toString() in
>>> your browsers console or by running the following JSON snippet through your
>>> JSON parser.
>>
>>> {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>>
>>> In affected JSON parsers the ID will not be converted successfully and will
>>> lose accuracy. In some parsers there may even be an exception.
>>
>>> The solution
>>> 
>>> To allow javascript and JSON parsers to read the IDs we need to include a
>>> string version of any ID when responding in the JSON format. What this means
>>> is Status, User, Direct Message and Saved Search IDs in the Twitter API will
>>> now be returned as an integer and a string in JSON responses. This will
>>> apply to the main Twitter API, the Streaming API and the Search API.
>>
>>> For example, a status object will now contain an id and an id_str. The
>>> following JSON representation of a status object shows the two versions of
>>> the ID fields for each data point.
>>
>>> [
>>>   {
>>> "coordinates": null,
>>> "truncated": false,
>>> "created_at": "Thu Oct 14 22:20:15 + 2010",
>>> "favorited": false,
>>> "entities": {
>>>   "urls": [
>>>   ],
>>>   "hashtags": [
>>>   ],
>>>   "user_mentions": [
>>> {
>>>   "name": "Matt Harris",
>>>   "id": 777925,
>>>   "id_str": "777925",
>>>   "indices": [
>>> 0,
>>> 14
>>>   ],
>>>   "screen_name": "themattharris"
>>> }
>>>   ]
>>> },
>>> "text": "@themattharris hey how are things?",
>>> "annotations": null,
>>> "contributors": [
>>>   {
>>> "id": 819797,
>>> "id_str": "819797",
>>> "screen_name": "episod"
>>>   }
>>> ],
>>> "id": 12738165059,
>>> "id_str": "12738165059",
>>> "retweet_count": 0,
>>> "geo": null,
>>> "retweeted": false,
>>> "in_reply_to_user_id": 777925,
>>> "in_reply_to_user_id_str": "777925",
>>> "in_reply_to_screen_name": "themattharris",
>>> "user": {
>>>   "id": 6253282
>>>   "id_str": "6253282"
>>> },
>>> "source": "web",
>>> "place": null,
>>> "in_reply_to_status_id": 12738040524
>>> "in_reply_to_status_id_str": "12738040524"
>>>   }
>>> ]
>>
>>> What should you do - RIGHT NOW
>>> --
>>> The first thing you should do is attempt to decode the JSON snippet

Re: [twitter-dev] Re: Snowflake: An update and some very important information

[Tom van der Woerdt]

Because a lot of Twitter applications (including my own) would go crazy
immediately.

Tom


On 10/19/10 6:09 AM, Detroitpro wrote:
> Out of curiosity; what advantage is there of including both the int
> and the string? Why not only offer the string and put the parsing on
> the client side?
> 
> Thanks,
> @detroitpro
> 
> On Oct 18, 8:34 pm, themattharris  wrote:
>> Thanks to @gotwalt for spotting the missing commas.
>>
>> Fixed JSON sample ...
>>
>> [
>>   {
>> "coordinates": null,
>> "truncated": false,
>> "created_at": "Thu Oct 14 22:20:15 + 2010",
>> "favorited": false,
>> "entities": {
>>   "urls": [
>>   ],
>>   "hashtags": [
>>   ],
>>   "user_mentions": [
>> {
>>   "name": "Matt Harris",
>>   "id": 777925,
>>   "id_str": "777925",
>>   "indices": [
>> 0,
>> 14
>>   ],
>>   "screen_name": "themattharris"
>> }
>>   ]
>> },
>> "text": "@themattharris hey how are things?",
>> "annotations": null,
>> "contributors": [
>>   {
>> "id": 819797,
>> "id_str": "819797",
>> "screen_name": "episod"
>>   }
>> ],
>> "id": 12738165059,
>> "id_str": "12738165059",
>> "retweet_count": 0,
>> "geo": null,
>> "retweeted": false,
>> "in_reply_to_user_id": 777925,
>> "in_reply_to_user_id_str": "777925",
>> "in_reply_to_screen_name": "themattharris",
>> "user": {
>>   "id": 6253282,
>>   "id_str": "6253282"
>> },
>> "source": "web",
>> "place": null,
>> "in_reply_to_status_id": 12738040524,
>> "in_reply_to_status_id_str": "12738040524"
>>   }
>> ]
>>
>> Best,
>> @themattharris
>>
>> On Oct 18, 5:19 pm, Matt Harris  wrote:
>>
>>> Last week you may remember Twitter planned to enable the new Status ID
>>> generator - 'Snowflake' but didn't. The purpose of this email is to explain
>>> the reason why this didn't happen, what we are doing about it, and what the
>>> new release plan is.
>>
>>> So what is Snowflake?
>>> --
>>> Snowflake is a service we will be using to generate unique Tweet IDs. These
>>> Tweet IDs are unique 64bit unsigned integers, which, instead of being
>>> sequential like the current IDs, are based on time. The full ID is composed
>>> of a timestamp, a worker number, and a sequence number.
>>
>>> The problem
>>> -
>>> Before launch it came to our attention that some programming languages such
>>> as Javascript cannot support numbers with >53bits. This can be easily
>>> examined by running a command similar to: (90071992547409921).toString() in
>>> your browsers console or by running the following JSON snippet through your
>>> JSON parser.
>>
>>> {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>>
>>> In affected JSON parsers the ID will not be converted successfully and will
>>> lose accuracy. In some parsers there may even be an exception.
>>
>>> The solution
>>> 
>>> To allow javascript and JSON parsers to read the IDs we need to include a
>>> string version of any ID when responding in the JSON format. What this means
>>> is Status, User, Direct Message and Saved Search IDs in the Twitter API will
>>> now be returned as an integer and a string in JSON responses. This will
>>> apply to the main Twitter API, the Streaming API and the Search API.
>>
>>> For example, a status object will now contain an id and an id_str. The
>>> following JSON representation of a status object shows the two versions of
>>> the ID fields for each data point.
>>
>>> [
>>>   {
>>> "coordinates": null,
>>> "truncated": false,
>>> "created_at": "Thu Oct 14 22:20:15 + 2010",
>>> "favorited": false,
>>> "entities": {
>>>   "urls": [
>>>   ],
>>>   "hashtags": [
>>>   ],
>>>   "user_mentions": [
>>> {
>>>   "name": "Matt Harris",
>>>   "id": 777925,
>>>   "id_str": "777925",
>>>   "indices": [
>>> 0,
>>> 14
>>>   ],
>>>   "screen_name": "themattharris"
>>> }
>>>   ]
>>> },
>>> "text": "@themattharris hey how are things?",
>>> "annotations": null,
>>> "contributors": [
>>>   {
>>> "id": 819797,
>>> "id_str": "819797",
>>> "screen_name": "episod"
>>>   }
>>> ],
>>> "id": 12738165059,
>>> "id_str": "12738165059",
>>> "retweet_count": 0,
>>> "geo": null,
>>> "retweeted": false,
>>> "in_reply_to_user_id": 777925,
>>> "in_reply_to_user_id_str": "777925",
>>> "in_reply_to_screen_name": "themattharris",
>>> "user": {
>>>   "id": 6253282
>>>   "id_str": "6253282"
>>> },
>>> "source": "web",
>>> "place": null,
>>> "in_reply_to_status_id": 12738040524
>>> "in_reply_to_status_id_str": "12738040524"
>>>   }
>>> ]
>>
>>> What should you do - RIGHT NOW
>>> ---

[twitter-dev] Facing 401 Error while getting RequestToken using Twitterizer

[Amer]

Hi,

I am facing 401 error on very very first step of getting Request
Token.
I am using Twitterizer for using API.
I am also pasting code here with my original consumer key:

TwitterAPIKey ="Ye4PF8qX9mqX1wZ4Nt5g"
TwitterConsumerKey="Ye4PF8qX9mqX1wZ4Nt5g"
TwitterConsumerSecretKey="Ye4PF8qX9mqX1wZ4Nt5g"
TwitterCallbackURL="http://localhost/BIT3/Members/Social.aspx";


OAuthTokenResponse RequestToken =
OAuthUtility.GetRequestToken(Configuration.TwitterConsumerKey,
Configuration.TwitterConsumerSecretKey,
Configuration.TwitterCallbackURL);


AnyHelp
Amer

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Snowflake: An update and some very important information

[Reivax]

Hi

In the case where an id is null (as in "in_reply_to_status_id":null )
what will the value of "in_reply_to_status_id_str" be ?

Thanks
Xavier

On 19 oct, 02:34, themattharris  wrote:
> Thanks to @gotwalt for spotting the missing commas.
>
> Fixed JSON sample ...
>
> [
>   {
>     "coordinates": null,
>     "truncated": false,
>     "created_at": "Thu Oct 14 22:20:15 + 2010",
>     "favorited": false,
>     "entities": {
>       "urls": [
>       ],
>       "hashtags": [
>       ],
>       "user_mentions": [
>         {
>           "name": "Matt Harris",
>           "id": 777925,
>           "id_str": "777925",
>           "indices": [
>             0,
>             14
>           ],
>           "screen_name": "themattharris"
>         }
>       ]
>     },
>     "text": "@themattharris hey how are things?",
>     "annotations": null,
>     "contributors": [
>       {
>         "id": 819797,
>         "id_str": "819797",
>         "screen_name": "episod"
>       }
>     ],
>     "id": 12738165059,
>     "id_str": "12738165059",
>     "retweet_count": 0,
>     "geo": null,
>     "retweeted": false,
>     "in_reply_to_user_id": 777925,
>     "in_reply_to_user_id_str": "777925",
>     "in_reply_to_screen_name": "themattharris",
>     "user": {
>       "id": 6253282,
>       "id_str": "6253282"
>     },
>     "source": "web",
>     "place": null,
>     "in_reply_to_status_id": 12738040524,
>     "in_reply_to_status_id_str": "12738040524"
>   }
> ]
>
> Best,
> @themattharris
>
> On Oct 18, 5:19 pm, Matt Harris  wrote:
>
> > Last week you may remember Twitter planned to enable the new Status ID
> > generator - 'Snowflake' but didn't. The purpose of this email is to explain
> > the reason why this didn't happen, what we are doing about it, and what the
> > new release plan is.
>
> > So what is Snowflake?
> > --
> > Snowflake is a service we will be using to generate unique Tweet IDs. These
> > Tweet IDs are unique 64bit unsigned integers, which, instead of being
> > sequential like the current IDs, are based on time. The full ID is composed
> > of a timestamp, a worker number, and a sequence number.
>
> > The problem
> > -
> > Before launch it came to our attention that some programming languages such
> > as Javascript cannot support numbers with >53bits. This can be easily
> > examined by running a command similar to: (90071992547409921).toString() in
> > your browsers console or by running the following JSON snippet through your
> > JSON parser.
>
> >     {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>
> > In affected JSON parsers the ID will not be converted successfully and will
> > lose accuracy. In some parsers there may even be an exception.
>
> > The solution
> > 
> > To allow javascript and JSON parsers to read the IDs we need to include a
> > string version of any ID when responding in the JSON format. What this means
> > is Status, User, Direct Message and Saved Search IDs in the Twitter API will
> > now be returned as an integer and a string in JSON responses. This will
> > apply to the main Twitter API, the Streaming API and the Search API.
>
> > For example, a status object will now contain an id and an id_str. The
> > following JSON representation of a status object shows the two versions of
> > the ID fields for each data point.
>
> > [
> >   {
> >     "coordinates": null,
> >     "truncated": false,
> >     "created_at": "Thu Oct 14 22:20:15 + 2010",
> >     "favorited": false,
> >     "entities": {
> >       "urls": [
> >       ],
> >       "hashtags": [
> >       ],
> >       "user_mentions": [
> >         {
> >           "name": "Matt Harris",
> >           "id": 777925,
> >           "id_str": "777925",
> >           "indices": [
> >             0,
> >             14
> >           ],
> >           "screen_name": "themattharris"
> >         }
> >       ]
> >     },
> >     "text": "@themattharris hey how are things?",
> >     "annotations": null,
> >     "contributors": [
> >       {
> >         "id": 819797,
> >         "id_str": "819797",
> >         "screen_name": "episod"
> >       }
> >     ],
> >     "id": 12738165059,
> >     "id_str": "12738165059",
> >     "retweet_count": 0,
> >     "geo": null,
> >     "retweeted": false,
> >     "in_reply_to_user_id": 777925,
> >     "in_reply_to_user_id_str": "777925",
> >     "in_reply_to_screen_name": "themattharris",
> >     "user": {
> >       "id": 6253282
> >       "id_str": "6253282"
> >     },
> >     "source": "web",
> >     "place": null,
> >     "in_reply_to_status_id": 12738040524
> >     "in_reply_to_status_id_str": "12738040524"
> >   }
> > ]
>
> > What should you do - RIGHT NOW
> > --
> > The first thing you should do is attempt to decode the JSON snippet above
> > using your production code parser. Observe the output to confirm the ID has
> > not lost accuracy.
>
> > What you do next depends on what happ

[twitter-dev] Re: Displaying custom media in the right pane

[Paul M. Watson]

> contentpartnersh...@twitter.com

This email bounced for me yesterday. I have tried part...@twitter.com
instead (no bounce but no reply yet neither.)

cheers,
Paul

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Twitter API Expertise?

[Zubin Wadia]

Working on an interesting private communications service with my team
and would like some help with Twitter OAuth + API implementation. If
any of you are interested in lending a hand (in exchange for
compensation ofcourse) please send me an email zwadia at gmail dot
com...

Cheers,

Zubin.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Snowflake: An update and some very important information

[Detroitpro]

Out of curiosity; what advantage is there of including both the int
and the string? Why not only offer the string and put the parsing on
the client side?

Thanks,
@detroitpro

On Oct 18, 8:34 pm, themattharris  wrote:
> Thanks to @gotwalt for spotting the missing commas.
>
> Fixed JSON sample ...
>
> [
>   {
>     "coordinates": null,
>     "truncated": false,
>     "created_at": "Thu Oct 14 22:20:15 + 2010",
>     "favorited": false,
>     "entities": {
>       "urls": [
>       ],
>       "hashtags": [
>       ],
>       "user_mentions": [
>         {
>           "name": "Matt Harris",
>           "id": 777925,
>           "id_str": "777925",
>           "indices": [
>             0,
>             14
>           ],
>           "screen_name": "themattharris"
>         }
>       ]
>     },
>     "text": "@themattharris hey how are things?",
>     "annotations": null,
>     "contributors": [
>       {
>         "id": 819797,
>         "id_str": "819797",
>         "screen_name": "episod"
>       }
>     ],
>     "id": 12738165059,
>     "id_str": "12738165059",
>     "retweet_count": 0,
>     "geo": null,
>     "retweeted": false,
>     "in_reply_to_user_id": 777925,
>     "in_reply_to_user_id_str": "777925",
>     "in_reply_to_screen_name": "themattharris",
>     "user": {
>       "id": 6253282,
>       "id_str": "6253282"
>     },
>     "source": "web",
>     "place": null,
>     "in_reply_to_status_id": 12738040524,
>     "in_reply_to_status_id_str": "12738040524"
>   }
> ]
>
> Best,
> @themattharris
>
> On Oct 18, 5:19 pm, Matt Harris  wrote:
>
> > Last week you may remember Twitter planned to enable the new Status ID
> > generator - 'Snowflake' but didn't. The purpose of this email is to explain
> > the reason why this didn't happen, what we are doing about it, and what the
> > new release plan is.
>
> > So what is Snowflake?
> > --
> > Snowflake is a service we will be using to generate unique Tweet IDs. These
> > Tweet IDs are unique 64bit unsigned integers, which, instead of being
> > sequential like the current IDs, are based on time. The full ID is composed
> > of a timestamp, a worker number, and a sequence number.
>
> > The problem
> > -
> > Before launch it came to our attention that some programming languages such
> > as Javascript cannot support numbers with >53bits. This can be easily
> > examined by running a command similar to: (90071992547409921).toString() in
> > your browsers console or by running the following JSON snippet through your
> > JSON parser.
>
> >     {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>
> > In affected JSON parsers the ID will not be converted successfully and will
> > lose accuracy. In some parsers there may even be an exception.
>
> > The solution
> > 
> > To allow javascript and JSON parsers to read the IDs we need to include a
> > string version of any ID when responding in the JSON format. What this means
> > is Status, User, Direct Message and Saved Search IDs in the Twitter API will
> > now be returned as an integer and a string in JSON responses. This will
> > apply to the main Twitter API, the Streaming API and the Search API.
>
> > For example, a status object will now contain an id and an id_str. The
> > following JSON representation of a status object shows the two versions of
> > the ID fields for each data point.
>
> > [
> >   {
> >     "coordinates": null,
> >     "truncated": false,
> >     "created_at": "Thu Oct 14 22:20:15 + 2010",
> >     "favorited": false,
> >     "entities": {
> >       "urls": [
> >       ],
> >       "hashtags": [
> >       ],
> >       "user_mentions": [
> >         {
> >           "name": "Matt Harris",
> >           "id": 777925,
> >           "id_str": "777925",
> >           "indices": [
> >             0,
> >             14
> >           ],
> >           "screen_name": "themattharris"
> >         }
> >       ]
> >     },
> >     "text": "@themattharris hey how are things?",
> >     "annotations": null,
> >     "contributors": [
> >       {
> >         "id": 819797,
> >         "id_str": "819797",
> >         "screen_name": "episod"
> >       }
> >     ],
> >     "id": 12738165059,
> >     "id_str": "12738165059",
> >     "retweet_count": 0,
> >     "geo": null,
> >     "retweeted": false,
> >     "in_reply_to_user_id": 777925,
> >     "in_reply_to_user_id_str": "777925",
> >     "in_reply_to_screen_name": "themattharris",
> >     "user": {
> >       "id": 6253282
> >       "id_str": "6253282"
> >     },
> >     "source": "web",
> >     "place": null,
> >     "in_reply_to_status_id": 12738040524
> >     "in_reply_to_status_id_str": "12738040524"
> >   }
> > ]
>
> > What should you do - RIGHT NOW
> > --
> > The first thing you should do is attempt to decode the JSON snippet above
> > using your production code parser. Observe the output to confirm the ID has
> > not lost accuracy.
>
> > What 

[twitter-dev] Re: Snowflake: An update and some very important information

[jon]

Hi,

You wrote that the IDs are "unsigned" 64 bit ints, but the IdWorker is
pumping out java Longs which are signed.  I'm assuming that was a
typo, but please clarify.

http://github.com/twitter/snowflake/blob/master/src/main/scala/com/twitter/service/snowflake/IdWorker.scala

Thanks,

- Jon

On Oct 18, 8:19 pm, Matt Harris  wrote:
> Last week you may remember Twitter planned to enable the new Status ID
> generator - 'Snowflake' but didn't. The purpose of this email is to explain
> the reason why this didn't happen, what we are doing about it, and what the
> new release plan is.
>
> So what is Snowflake?
> --
> Snowflake is a service we will be using to generate unique Tweet IDs. These
> Tweet IDs are unique 64bit unsigned integers, which, instead of being
> sequential like the current IDs, are based on time. The full ID is composed
> of a timestamp, a worker number, and a sequence number.
>
> The problem
> -
> Before launch it came to our attention that some programming languages such
> as Javascript cannot support numbers with >53bits. This can be easily
> examined by running a command similar to: (90071992547409921).toString() in
> your browsers console or by running the following JSON snippet through your
> JSON parser.
>
>     {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>
> In affected JSON parsers the ID will not be converted successfully and will
> lose accuracy. In some parsers there may even be an exception.
>
> The solution
> 
> To allow javascript and JSON parsers to read the IDs we need to include a
> string version of any ID when responding in the JSON format. What this means
> is Status, User, Direct Message and Saved Search IDs in the Twitter API will
> now be returned as an integer and a string in JSON responses. This will
> apply to the main Twitter API, the Streaming API and the Search API.
>
> For example, a status object will now contain an id and an id_str. The
> following JSON representation of a status object shows the two versions of
> the ID fields for each data point.
>
> [
>   {
>     "coordinates": null,
>     "truncated": false,
>     "created_at": "Thu Oct 14 22:20:15 + 2010",
>     "favorited": false,
>     "entities": {
>       "urls": [
>       ],
>       "hashtags": [
>       ],
>       "user_mentions": [
>         {
>           "name": "Matt Harris",
>           "id": 777925,
>           "id_str": "777925",
>           "indices": [
>             0,
>             14
>           ],
>           "screen_name": "themattharris"
>         }
>       ]
>     },
>     "text": "@themattharris hey how are things?",
>     "annotations": null,
>     "contributors": [
>       {
>         "id": 819797,
>         "id_str": "819797",
>         "screen_name": "episod"
>       }
>     ],
>     "id": 12738165059,
>     "id_str": "12738165059",
>     "retweet_count": 0,
>     "geo": null,
>     "retweeted": false,
>     "in_reply_to_user_id": 777925,
>     "in_reply_to_user_id_str": "777925",
>     "in_reply_to_screen_name": "themattharris",
>     "user": {
>       "id": 6253282
>       "id_str": "6253282"
>     },
>     "source": "web",
>     "place": null,
>     "in_reply_to_status_id": 12738040524
>     "in_reply_to_status_id_str": "12738040524"
>   }
> ]
>
> What should you do - RIGHT NOW
> --
> The first thing you should do is attempt to decode the JSON snippet above
> using your production code parser. Observe the output to confirm the ID has
> not lost accuracy.
>
> What you do next depends on what happens:
>
> * If your code converts the ID successfully without losing accuracy you are
> OK but should consider converting to the _str versions of IDs as soon as
> possible.
> * If your code has lost accuracy, convert your code to using the _str
> version immediately. If you do not do this your code will be unable to
> interact with the Twitter API reliably.
> * In some language parsers, the JSON may throw an exception when reading the
> ID value. If this happens in your parser you will need to ‘pre-parse’ the
> data, removing or replacing ID parameters with their _str versions.
>
> Summary
> -
> 1) If you develop in Javascript, know that you will have to update your code
> to read the string version instead of the integer version.
>
> 2) If you use a JSON decoder, validate that the example JSON, above, decodes
> without throwing exceptions. If exceptions are thrown, you will need to
> pre-parse the data. Please let us know the name, version, and language of
> the parser which throws the exception so we can investigate.
>
> Timeline
> ---
> by 22nd October 2010 (Friday): String versions of ID numbers will start
> appearing in the API responses
> 4th November 2010 (Thursday) : Snowflake will be turned on but at ~41bit
> length
> 26th November 2010 (Friday) : Status IDs will break 53bits in length and
> cease being usable as Integers in Javascript 

[twitter-dev] Re: Snowflake: An update and some very important information

[jon]

Hi,

Will user ids be generated by snowflake in the near future?  Is it
safe to parse and store them as signed 64bit integers?

Thanks.

On Oct 18, 8:34 pm, themattharris  wrote:
> Thanks to @gotwalt for spotting the missing commas.
>
> Fixed JSON sample ...
>
> [
>   {
>     "coordinates": null,
>     "truncated": false,
>     "created_at": "Thu Oct 14 22:20:15 + 2010",
>     "favorited": false,
>     "entities": {
>       "urls": [
>       ],
>       "hashtags": [
>       ],
>       "user_mentions": [
>         {
>           "name": "Matt Harris",
>           "id": 777925,
>           "id_str": "777925",
>           "indices": [
>             0,
>             14
>           ],
>           "screen_name": "themattharris"
>         }
>       ]
>     },
>     "text": "@themattharris hey how are things?",
>     "annotations": null,
>     "contributors": [
>       {
>         "id": 819797,
>         "id_str": "819797",
>         "screen_name": "episod"
>       }
>     ],
>     "id": 12738165059,
>     "id_str": "12738165059",
>     "retweet_count": 0,
>     "geo": null,
>     "retweeted": false,
>     "in_reply_to_user_id": 777925,
>     "in_reply_to_user_id_str": "777925",
>     "in_reply_to_screen_name": "themattharris",
>     "user": {
>       "id": 6253282,
>       "id_str": "6253282"
>     },
>     "source": "web",
>     "place": null,
>     "in_reply_to_status_id": 12738040524,
>     "in_reply_to_status_id_str": "12738040524"
>   }
> ]
>
> Best,
> @themattharris
>
> On Oct 18, 5:19 pm, Matt Harris  wrote:
>
>
>
> > Last week you may remember Twitter planned to enable the new Status ID
> > generator - 'Snowflake' but didn't. The purpose of this email is to explain
> > the reason why this didn't happen, what we are doing about it, and what the
> > new release plan is.
>
> > So what is Snowflake?
> > --
> > Snowflake is a service we will be using to generate unique Tweet IDs. These
> > Tweet IDs are unique 64bit unsigned integers, which, instead of being
> > sequential like the current IDs, are based on time. The full ID is composed
> > of a timestamp, a worker number, and a sequence number.
>
> > The problem
> > -
> > Before launch it came to our attention that some programming languages such
> > as Javascript cannot support numbers with >53bits. This can be easily
> > examined by running a command similar to: (90071992547409921).toString() in
> > your browsers console or by running the following JSON snippet through your
> > JSON parser.
>
> >     {"id": 10765432100123456789, "id_str": "10765432100123456789"}
>
> > In affected JSON parsers the ID will not be converted successfully and will
> > lose accuracy. In some parsers there may even be an exception.
>
> > The solution
> > 
> > To allow javascript and JSON parsers to read the IDs we need to include a
> > string version of any ID when responding in the JSON format. What this means
> > is Status, User, Direct Message and Saved Search IDs in the Twitter API will
> > now be returned as an integer and a string in JSON responses. This will
> > apply to the main Twitter API, the Streaming API and the Search API.
>
> > For example, a status object will now contain an id and an id_str. The
> > following JSON representation of a status object shows the two versions of
> > the ID fields for each data point.
>
> > [
> >   {
> >     "coordinates": null,
> >     "truncated": false,
> >     "created_at": "Thu Oct 14 22:20:15 + 2010",
> >     "favorited": false,
> >     "entities": {
> >       "urls": [
> >       ],
> >       "hashtags": [
> >       ],
> >       "user_mentions": [
> >         {
> >           "name": "Matt Harris",
> >           "id": 777925,
> >           "id_str": "777925",
> >           "indices": [
> >             0,
> >             14
> >           ],
> >           "screen_name": "themattharris"
> >         }
> >       ]
> >     },
> >     "text": "@themattharris hey how are things?",
> >     "annotations": null,
> >     "contributors": [
> >       {
> >         "id": 819797,
> >         "id_str": "819797",
> >         "screen_name": "episod"
> >       }
> >     ],
> >     "id": 12738165059,
> >     "id_str": "12738165059",
> >     "retweet_count": 0,
> >     "geo": null,
> >     "retweeted": false,
> >     "in_reply_to_user_id": 777925,
> >     "in_reply_to_user_id_str": "777925",
> >     "in_reply_to_screen_name": "themattharris",
> >     "user": {
> >       "id": 6253282
> >       "id_str": "6253282"
> >     },
> >     "source": "web",
> >     "place": null,
> >     "in_reply_to_status_id": 12738040524
> >     "in_reply_to_status_id_str": "12738040524"
> >   }
> > ]
>
> > What should you do - RIGHT NOW
> > --
> > The first thing you should do is attempt to decode the JSON snippet above
> > using your production code parser. Observe the output to confirm the ID has
> > not lost accuracy.
>
> > What you do next depends on what happens

[twitter-dev] Authentication error

[j2me]

Sorry for duplicate post, but since the previous post was old I think
nobody caught eyes.

My previous post was here
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/3723503993279c5e/d1d9278f754030e8?lnk=gst&q=login+error#d1d9278f754030e8

My problem was, I could not  login successfully using mobile internet.
but using pc internet i can login successfully. I tried this in lot of
devices, in all case i could not success. Using wifi in mobile the
problem did not occurred. As far as I know, it is occurring in GPRS.

Is anyone  familiar to this problem and solved??

Thanks

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: [twitcurl Lib] Direct Message signbase string

[balbari]

at the end of URL part should I remove a '?' ?

BAD ==> POST&http%3A%2F%2Ftwitter.com%2Fdirect_messages%2Fnew.xml%3F
GOOD ==> POST&http%3A%2F%2Ftwitter.com%2Fdirect_messages%2Fnew.xml

GOOD case right?


On 10월19일, 오후5시15분, Tom van der Woerdt  wrote:
> Looks like there's a '?' in the URL part. Shouldn't be there.
>
> Tom
>
> On Oct 19, 2010, at 7:24 AM, balbari  wrote:
>
>
>
> > I'm using twitcurl library.
>
> > When you send a direct message an error occurs.
>
> > Error Message : Incorrect signature
>
> > When I send a message signbase string is shown below.
>
> > POST&http%3A%2F%2Ftwitter.com%2Fdirect_messages%2Fnew.xml%3F
> > screen_name%3DRECEIVERNM&
> > oauth_consumer_key%3DCKEY%26
> > oauth_nonce%3D1287392764ed%26
> > oauth_signature_method%3DHMAC-SHA1%26
> > oauth_timestamp%3D1287392764%26
> > oauth_token%3DATOKEN%26
> > oauth_version%3D1.0%26
> > text%3D12345"
>
> > See you on the signbase wrong ones?
> > If you know something is wrong, please correct parts.
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this 
> > group:http://groups.google.com/group/twitter-development-talk- 원본 텍스트 숨기기 -
>
> - 원본 텍스트 보기 -

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] [twitcurl Lib] Direct Message signbase string

[Tom van der Woerdt]

Looks like there's a '?' in the URL part. Shouldn't be there.

Tom


On Oct 19, 2010, at 7:24 AM, balbari  wrote:

> I'm using twitcurl library.
> 
> When you send a direct message an error occurs.
> 
> Error Message : Incorrect signature
> 
> When I send a message signbase string is shown below.
> 
> POST&http%3A%2F%2Ftwitter.com%2Fdirect_messages%2Fnew.xml%3F
> screen_name%3DRECEIVERNM&
> oauth_consumer_key%3DCKEY%26
> oauth_nonce%3D1287392764ed%26
> oauth_signature_method%3DHMAC-SHA1%26
> oauth_timestamp%3D1287392764%26
> oauth_token%3DATOKEN%26
> oauth_version%3D1.0%26
> text%3D12345"
> 
> See you on the signbase wrong ones?
> If you know something is wrong, please correct parts.
> 
> -- 
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group: 
> http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Unauthorized 401 error

[Andrew Cross. Gna]

I did the following

1. Registered an application
2. Got the required details from the application registration with
Twitter i.e. consumer Key and the secret
3. Implemented oAuthBase.cs class available in the google code
storage.

The authorization done at the first time successfuly and worked
perfectly well. But when we try to connect with the twitter with the
oauth_token and oauth_verifier details passed in the query string.
But, I received the error as Unauthorized 401 error. I tried in the
following also.

1. At first the call back URL set to be localhost for the testing
purpose and later it is being removed and accessed the call back URL
set in the application settings.
2. Tried to store the nonce value since it is generated randomly and
may be chances to get the variable values at every time.

Is there anyother ways to analyze and rectify this error?

Thanks in advance

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] Re: Cross-domain policy file

[Orian Marx (@orian)]

Zeh, thanks for taking the time to bring this issue to light again and
to present so many examples of other significant APIs that do not have
restrictive crossdomain policies. As you note, this issue has been
brought to Twitter's attention several times over the last few years
but to no avail.

For my work I continue to have to rely on a PHP proxy for all calls
between my Flash client and Twitter. This is certainly not ideal.

Team Twitter, it's time for you to address this issue. One of the most
popular clients for Twitter out there, TweetDeck, is built with Flash
technology and yet runs as an AIR app I'm guessing in part because
that has a different security model and does not have to deal with
this. You should recognize that there is a large pool of developer
talent that has, over the years, attempted to build wonderful things
on your platform but have thrown up their hands and left due to
frustration with this crossdomain policy. Please stop treating us as
second class developers.

Thanks,
Orian

On Oct 18, 3:34 pm, zeh fernando  wrote:
> Does Twitter have any plans on when/whether they'll change its current
> cross-domain policy file?
>
> http://api.twitter.com/crossdomain.xmldoes not allow requests from
> Flash-based websites and web apps because it restricts response to
> twitter.com subdomains.
>
> http://search.twitter.com/crossdomain.xml, however, does allow Flash
> requests from any domain.
>
> This policy pretty much renders all Flash calls to the API useless
> (unless they're search calls).
>
> One could use proxy scripts, but given the limitations imposed by the
> Twitter API (150 calls per IP per hour), it means public websites are
> out of luck if they're getting any kind of public data without
> authenticating like, say, getting a (public) user timeline.
>
> This has been discussed at length in previous threads.
>
> Change in 
> crossdomain.xml??http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> Most curiously, the above thread mentions on March 2008 that Twitter
> would be moving API calls to api.twitter.com and allowing a more
> permissive crossdomain policy file there in a few months. This hasn't
> happened, though, since people have continued to be dumbfounded by the
> inability to load Twitter data from Flash-based web apps.
>
> Twitter Stream 
> crossdomain.xmlhttp://groups.google.com/group/twitter-development-talk/browse_thread...
>
> I think this decision is specially questionable as the cross-domain
> restrictions in place do nothing else other than put a tax on what
> people can do from Flash-based web apps, but also allow any other
> usage from any other technology, be it a security issue or not. In
> fact, even using PHP proxies one could make the API calls from Flash
> (albeit in a restricted manner) so I can't see a real reason for
> singling out/blocking this platform.
>
> Normally, public APIs add no such artificial/ineffective restrictions,
> and simply allow any kind of connection (doing their own top of their
> own built-in restrictions and rate limiting)...
>
> http://graph.facebook.com/crossdomain.xml- allows connections from
> all domainshttp://api.flickr.com/crossdomain.xml- allows connections from all
> domainshttp://api.plixi.com/crossdomain.xml- allows connections from all
> domainshttp://api.bit.ly/crossdomain.xml- allows connections from all
> domainshttp://stream.twitvid.com/crossdomain.xml- allows connections from
> all domains
> ...etc etc
>
> So, is there any clear reason why the restriction is still in place?
> Or any idea on when this policy will be reviewed?
>
> Thanks,
> Zeh

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] status destroy / caching in NewTwitter.

[Pradeep Senanayake]

HI, Tom,

What I just want to know is, how to get access tokens dynamically, using
https://api.twitter.com/oauth/request_token
url. I went through the documentation but I cant understand. Pls give me a
clue.

Thanks in advance.
Pradeep.

On Wed, Oct 6, 2010 at 12:42 AM, Tom Monaghan  wrote:

> Hi folks,
>
> Can someone please share the caching expiration plan for newtwitter?
> It seems to cache new content for a really, really long time (at least
> 12 hours, though I think this number is falling).
>
> A few of our apps will regularly destroy some of their past tweets.
> Users with oldtwitter will not see said tweet if they haven't had it
> in their stream, and if it is in their stream, will lose it in their
> first refresh or authentication cycle.  This is our expected behavior.
>
> Users with newtwitter will see those tweets, even after they have been
> destroyed.  Even if they didn't have an active session during the time
> of their creation / destruction.
>
> You can manually flush your home timeline's cache by leaving the
> preview to return to oldtwitter.  If you then go back to newtwitter,
> they stay gone.  Signing out / signing back in to newtwitter and
> destroyed tweets are still there.
>
> What are the new caching expiration values?  Are there plans to
> decrease them?  Is there a goal min/max that we can expect?  Is what
> I've described expected behavior?
>
> Any help would be appreciated.
>
> Thanks much,
> Tom
>
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk
>

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk