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

Reply via email to