> 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.
