[twitter-dev] Re: screen_name param for /statuses/mentions and/or xml format for search results?
> No, frankly, I didn't put 2 and 2 together on the piece of info you're > looking for; the XML aspect of your subject confuses focus. Well, sorry about that ... it's referred to as the "xml format" in all of the API docs, and it has no DTD or XSD schema to infer a better name from. so that's how i referred to it -- for future reference, is there some other name people use to refer to that format option on this list? > in-memory. That scenario has simply never been a problem for me. A > minor amount of additional work and resources required, but the > server-side business-centric apps I work with have a lot of state to > begin with. > > I wouldn't mind seeing full XML info available in the search API, but > it doesn't seem like much of a stretch to separately retrieve and > cache that sort of info either. I have no problem maintaining state, i am happily maintaining all the state and history i can about the user est i'm interested in -- and i'd even be willing to maintain state about every tweet ever to twtiter that refers to one those users by name ... if there was an easy way to get that info. But fetching each of those tweet individually seems ridiculous and prohibitive, especially since all my app cares about is tweets that are replies -- there's no way to filter on that type of information using the search API, so most of the individual tweets i have to retrieve (one at a time) don't even have the data neccessary to make them worth maintaining state about. your example of caching user data is one thing: it's trivial to cache all the metadata about a finite set of users, but you can't cache tweets that haven't happened yet.
[twitter-dev] Re: screen_name param for /statuses/mentions and/or xml format for search results?
No, frankly, I didn't put 2 and 2 together on the piece of info you're
looking for; the XML aspect of your subject confuses focus.
When I've had to cross-correlate between search and main API in the
past, such as pulling search feeds for display elsewhere, and needing
additional user info on the person sending the tweet in said feed, I
pull the search feed ATOM and work against my main XML results
in-memory. That scenario has simply never been a problem for me. A
minor amount of additional work and resources required, but the
server-side business-centric apps I work with have a lot of state to
begin with.
I wouldn't mind seeing full XML info available in the search API, but
it doesn't seem like much of a stretch to separately retrieve and
cache that sort of info either.
∞ Andy Badera
∞ +1 518-641-1280
∞ This email is: [ ] bloggable [x] ask first [ ] private
∞ Google me: http://www.google.com/search?q=("andrew badera") OR ("andy badera")
On Sun, Sep 6, 2009 at 2:40 AM, Hoss wrote:
>
>
>
> On Sep 4, 4:43 pm, Andrew Badera wrote:
>> ATOM _is_ XML ... not sure what the problem is?
>
> Uh, yes ... at a basic level that's true -- but the fact that you
> would point that out suggests that you aren't remotely familiar with
> the various response formats twitter API calls. Let me explain what
> little i do know...
>
> Twitter supports 4 output formats (that i know of): json, atom, rss,
> and a twitter specific xml schema. In the documentation for every api
> method, there is a "Formats" section that lists which formats are
> supported for that API call and they are refered to as "json", "atom",
> "rss", and "xml" ... you pick the format you want by specifying the
> format as the extension on your rest call. Here is an example of an
> API that supports all three formats...
>
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-public_timeline
> http://twitter.com/statuses/public_timeline.xml
> http://twitter.com/statuses/public_timeline.atom
> http://twitter.com/statuses/public_timeline.rss
> http://twitter.com/statuses/public_timeline.json
>
> ...all of these URLs return the same objects, but in different formats
> -- and as you can see, when you specify the "xml" formats you get a
> *lot* more details about each of the status objects then when using
> the "atom" or "rss" formats.
>
> My question was regarding the fact that since the search api doesn't
> support "xml" (as you can see in the "Formats" section of the docs:
> http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search) I
> don't see any way to get the in_reply_to information, without fetching
> each individual status message returned.
>
> (And yes: the search api does support the json format, and the json
> format *usually* includes the in_reply_to info, but not when using the
> search API)
>
> Now does my question make more sense to you?
>
>
[twitter-dev] Re: screen_name param for /statuses/mentions and/or xml format for search results?
On Sep 4, 4:43 pm, Andrew Badera wrote: > ATOM _is_ XML ... not sure what the problem is? Uh, yes ... at a basic level that's true -- but the fact that you would point that out suggests that you aren't remotely familiar with the various response formats twitter API calls. Let me explain what little i do know... Twitter supports 4 output formats (that i know of): json, atom, rss, and a twitter specific xml schema. In the documentation for every api method, there is a "Formats" section that lists which formats are supported for that API call and they are refered to as "json", "atom", "rss", and "xml" ... you pick the format you want by specifying the format as the extension on your rest call. Here is an example of an API that supports all three formats... http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-public_timeline http://twitter.com/statuses/public_timeline.xml http://twitter.com/statuses/public_timeline.atom http://twitter.com/statuses/public_timeline.rss http://twitter.com/statuses/public_timeline.json ...all of these URLs return the same objects, but in different formats -- and as you can see, when you specify the "xml" formats you get a *lot* more details about each of the status objects then when using the "atom" or "rss" formats. My question was regarding the fact that since the search api doesn't support "xml" (as you can see in the "Formats" section of the docs: http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search) I don't see any way to get the in_reply_to information, without fetching each individual status message returned. (And yes: the search api does support the json format, and the json format *usually* includes the in_reply_to info, but not when using the search API) Now does my question make more sense to you?
[twitter-dev] Re: screen_name param for /statuses/mentions and/or xml format for search results?
ATOM _is_ XML ... not sure what the problem is? ∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me: http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera) On Fri, Sep 4, 2009 at 6:18 PM, Hoss wrote: > > Background... > > I'm attempting to build an app that can display a "conversation graph" > of all the tweets to/from people in a small group ... the use case > being a set of friends, or coworkers in an office all wanting a quick > view of the various public tweets and public reply tweets posted by > other people in the group -- along with the full context of those > tweets: tweets they are in reply to, or replies to those tweets, even > if they are from people not included in the group. > > Current Approach... > > The /statuses/user_status REST API makes it trivial to get public > tweets *by* a set of known individuals and using the XML format i can > immediately inspect the "in_reply_to_status_id" element to see if > there is a "parent" status i should fetch using /statuses/show to > fetch the previous tweets for context context on the conversation -- > even those tweets were from "outside users" not in the group. The > next step is to find public statuses posted *from* outside users in > reply to tweets by users who *are*in my set. The "to" param of the / > search API makes it fairly easy to find a super set of these messages, > but there's just one catch... > > The Problem... > > The /search API only supports the "atom" and "json" formats; since it > doesn't support the "xml" format option, the only way (i can see) to > determine if an item returned by /search is an actual reply to a > previous tweet (and not just a shout out) is to fetch each individual > tweet using the /status/show API ... but that feels like a very > hackish solution, requiring numerous REST fetches of tweets (one at a > time using the /statuses/show) just to backfill one additional > property. > > In an ideal world the /search API would support the xml format so > "in_reply_to_status_id" was included in the response, and things that > weren't a reply could be easily excluded. (even better: if there was > an optional param on the /search API that would allow you to restrict > the results to only tweets that were replies) > > Alternately: it would be really great if the /statuses/mentions API > (which does support the xml format) didn't require authentication, and > allowed clients to pass a screen_name param to fetch public tweets > mentioning a specific user. > > The Question... > > Obviously, my comments above constitute a suggested change to the > existing APIs, but does anyone see any solutions to the problem i > describe that would be less kludgy then using the /statuses/show API > to fetch *every* individual item returned by the /search API in order > to get the "in_reply_to_status_id" ? > > > > >
