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:

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" ?

Reply via email to