As well as everything that others have asked, I'm also concerned about the following:
1) Does this mean that tweets can effectively be infinite length - say I write a tweet with 120 chars of text and then http://www.a-really-really-really-long-url-maybe-with-a-message-encoded.com/in-the-middle-of-it- that will then get counted as 140 chars after the link has been wrapped. When we come to display that, we have to be able to correctly format with realistically, anything up to 200 char statuses. 2) What will be coming out of the search API? Will those tweets have t.colinks in them? If so, will we get the additional entity data? Tom On Wed, Jun 9, 2010 at 3:46 PM, Rich <rhyl...@gmail.com> wrote: > I'm a +1 one for the huge can of worms this is going to cause with > realtime character counting. Here are my concerns > > 1) An app realtime character counts what is entered in a text box and > that could end up being wrong when posted (and in the mobile space > making ANOTHER http call just get yet another shortener is not > realistic) > > 2) If the user has a bit.ly link, for example, and it's only say 15 > characters long and they post at 136 characters, it'll get rejected > from Twitter whilst the client app said it was ok. > > 3) After the system has launch we could dynamically look at urls, > ignore their character count and substitute it for 20 characters, > however for iPhone developers we have AT LEAST a week's wait to get > these things through Apple's approval process. > > But it's not just iPhone developers, all developers can't just push > out code that quickly without a decent amount of testing > > We can't realistically do that until the system is live... and yet the > apps will be 'broken' in the time between 'go live' and end of testing/ > approval. > > Do you see the chicken and the egg scenario here? > > My proposal is you need to keep the 140 limit as it is now, if your > own link shortener makes it over 140 then so be it, that's your > decision, not ours... but the original posted text was 140. > > On Jun 9, 2:30 pm, "Brian Smith" <br...@briansmith.org> wrote: > > Dewald Pretorius wrote: > > > StatusNet, blog, etc.). If the privacy argument carried any water, then > > bit.ly > > > would be a far greater privacy threat than Twitter. > > > > I agree, and that's why I (and others) were working on solutions to get > > around bit.ly and other link shorteners. And, Twitter has already > developed > > the ultimate solution to that privacy issue, but they just are refusing > to > > let API developers use it. That is what is so incredibly frustrating. > > > > Regards, > > Brian >
