This is not a priority internally so we would love to see you create one yourself. If anything, it could give us some ideas of what we may want to adopt in the future.
Thanks, Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 8, 2009 at 9:00 AM, Khang Toh <[email protected]> wrote: > > Hi Alex > > I just want to bring up this topic since we are in the process of > developing a structured query language for Twitter API for our app. > Just want to know is Twitter has intend to go this direction, it's > good for us to know and instead of duplicating efforts in making > Twitter API better! Thanks! > > Khang > > On Mar 23, 2:40 pm, Alex Payne <[email protected]> wrote: > > Thanks for the feedback. > > > > > > > > On Sun, Mar 22, 2009 at 20:46, Zac Bowling <[email protected]> wrote: > > > > > If it was built and twitter charged something similar to the rate that > > > Amazon's SimpleDB charges for processing power required to preform the > > >query, I would gladly pay. > > > > > Zac Bowling > > > > > On Sun, Mar 22, 2009 at 7:14 PM, Zac Bowling <[email protected]> > wrote: > > >> There was the one I mentioned in my first email that was a bridge with > > >> MSSQL (Tweet-SQL) but that is nothing more then a bunch of managed > > >> (written in c#) stored procedure calls for MSSQL 2005 which maybe what > > >> you are thinking of. That's not really anything close to what I'm > > >> looking for. > > > > >> It doesn't even have to be SQL like but just a some kind of structured > > >>querylanguage for twitter. That would be awesome. > > > > >> Zac Bowling > > > > >> On Sun, Mar 22, 2009 at 4:49 PM, Abraham Williams <[email protected]> > wrote: > > >>> I'm positive that a third party was providing a tql api for their > database > > >>> of tweets and that it was announced on this list but now searching > returns > > >>> nothing. Does anybody else remember this? Maybe it was a dream... > > > > >>> On Sun, Mar 22, 2009 at 15:28, Zac Bowling <[email protected]> > wrote: > > > > >>>> I would love it if Twitter would develop an equivalent to Facebook's > > >>>> FQL, Yahoo's YQL, Amazon's SimpleDB, or Google's GQL (used for app > > >>>> engine data storage). > > > > >>>> Basically an abstracted SQL-likequeryengine for doing queries and > > >>>> getting back data the data you want using virtual tables of > different > > >>>> data twitter serves up. > > > > >>>> You could do something basic like: > > > > >>>> SELECT StatusID, UserID, Text FROM StatusUpdates as S > > >>>> WHERE > > >>>> S.UserID in (SELECT UserID FROM SocialGraph WHERE > FollowerUseringID > > >>>> = MYUSERID) and > > >>>> S.StatusID > LASTID > > >>>> ORDER BY S.StatusID DESC > > >>>> LIMIT 200 > > > > >>>> to get a basic user's following timeline or whatever. From there you > > >>>> can build on from that and get a bit more complex. > > > > >>>> It could even build on from justquerysyntax to modify and > destructive > > >>>> calls. > > > > >>>> Maybe something like: > > >>>> DELETE FROM StatusUpdates WHERE StatusID = 200102; > > > > >>>> or: > > >>>> INSERT INTO StatusUpdates(text,replyToStatusID,replyToUserID) VALUES > > >>>> ('@johnsmith hello',123601020,235133); > > > > >>>> or: > > >>>> UPDATE StatusUpdates SET favorite = TRUE WHERE StatusID = 123601020; > > > > >>>> You could do it where you do an HTTP get/post with aquerylike above > > >>>> to twitter's rest api, and the results could come back as JSON or > XML > > >>>> or whatever. > > > > >>>> Some concepts like this could be done in a local side wrapper (like > > >>>> I've seen a SQL bridge for MSSQL for twitter on here a while back) > but > > >>>> it would be awesome if these were processed twitter server side. If > > >>>> done right, it can save on overhead on both twitter and from the > > >>>> client side. > > > > >>>> Like in one case I have where I'm hitting the following timeline, > I'm > > >>>> missing something out of the user structure that you get back from > > >>>> that, so I turn around and do another user call on user for each > tweet > > >>>> to get that data. Half the data I get back in both cases don't use > on > > >>>> both calls but it would be awesome to be able to get that data in > one > > >>>> call. > > > > >>>> A lot to consider around optimization and limits and a bit of work > to > > >>>> build it but I think something like that would be really useful. > > > > >>>> Zac > > > > >>> -- > > >>> Abraham Williams |http://the.hackerconundrum.com > > >>> Web608 | Community Evangelist |http://web608.org > > >>> This email is: [ ] blogable [x] ask first [ ] private. > > >>> Sent from: Madison WI United States. > > > > -- > > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x >
