[twitter-dev] Re: screen_name param for /statuses/mentions and/or xml format for search results?

2009-09-08 Thread Hoss

 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?

2009-09-06 Thread Hoss



On Sep 4, 4:43 pm, Andrew Badera and...@badera.us 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?

2009-09-04 Thread Andrew Badera

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, Hosshoss...@gmail.com 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 ?