probably not - we're just going to stick with JSON and XML for a bit now.
On Thu, Apr 15, 2010 at 8:52 AM, M. Edward (Ed) Borasky <zzn...@gmail.com>wrote:
> I guess I need to look at the "protocol buffers" spec again. And some
> of the "binary JSON" formats. While we're dreaming, how about sending
> Streaming data *compressed*? ;-)
> On Apr 15, 7:49 am, Raffi Krikorian <ra...@twitter.com> wrote:
> > a way to think about this is analogous to geo. people used to put geo
> > information in the 140 characters -- but now, we allow you to put it out
> > band in a machine-readable way. we want to extend that functionality to
> > types of meta data (links to URLs, etc.).
> > 2010/4/15 André Luís <andreluis...@gmail.com>
> > > Why shorten links that won't count for 140 limit and are not viewed by
> > > user? It will only add un-needed requests and waste values on the
> > > shortener.
> > > André Luís
> > > On Apr 15, 2010 2:18 p.m., "M. Edward (Ed) Borasky" <zzn...@gmail.com>
> > > wrote:
> > > I'm thinking of something like the RFC process for Internet protocols.
> > > By the way, on a related note, once the "Twitter link shortener" I've
> > > been hearing rumors about is in place, can we have all the links in
> > > tweets sent from the API shortened with it? Profile images, user
> > > object URLs, etc. ;-)
> > > Part of this stems from my concern over something I thought I heard
> > > yesterday about Twitter building its own "place" database. There are
> > > dozens of place databases - why does Twitter need another one?
> > > On Apr 15, 6:05 am, Raffi Krikorian <ra...@twitter.com> wrote:
> > > > please feel free to point us to standards that you would like us to >
> > > consider. we are really att...
> > > > On Thu, Apr 15, 2010 at 12:09 AM, <zn...@comcast.net> wrote: >
> > > > > ----- "Jud" <jvale...@gmail.com> wrote: > > > > On Apr 14, 5:05
> > > James Teters <jtet...@gmail....
> > --
> > Raffi Krikorian
> > Twitter Platform Teamhttp://twitter.com/raffi
Twitter Platform Team