+1 agreed

On Oct 23, 2009, at 7:20 PM, Dewald Pretorius wrote:

Instead of all of us having to do fancy tap-dances, the proper
solution is for Twitter to issue an error response when a sent tweet
is rejected for whatever reason.


On Oct 23, 7:58 pm, AJ Chen <cano...@gmail.com> wrote:
then, comparing the front part (without url at the end) of the status is
probably sufficient. -aj

On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius <dpr...@gmail.com> wrote:

You cannot compare the status sent with the status returned when the
status contains an URL. The returned status contains Twitter's own
bit.ly shortened URL instead of the URL your status sent had.


On Oct 23, 6:24 pm, AJ Chen <cano...@gmail.com> wrote:
I noticed this behavior a long time ago (may be a month) and reported the problem on this list, but it did not get any response from the api team.
thought it was a bug, but just realized yesterday that the api probably ignores 140+ chars status update intentionally. but' I'm not sure this is the policy or temporary tactic to reduce workload on api. it would be
that api team can clasify on this issue. to check if this happens or not, you can compare the status sent to api and the status returned from api
your application code.

On Fri, Oct 23, 2009 at 1:51 PM, Naveen <knig...@gmail.com> wrote:

Here are two threads related to this issue.

http://groups.google.com/group/twitter-development-talk/browse_thread .

http://groups.google.com/group/twitter-development-talk/browse_thread .

It is an inconvenient change, not because they changed it, but because
they did not announce that the change was happening.

On Oct 21, 5:37 am, Dave Sherohman <d...@fishtwits.com> wrote:
On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote:
Has anyone else noticed a change in the way that the 140 character limit is enforced via the API? I noticed a change sometime between
13th and the 16th that is now causing all my 140+ character posts
be rejected by the API.
Also a side note is that the api is not returning errors, they
proper responses however they are the proper response for the
status of the account, not the new status that was just attempted
be posted.

My users first reported issues arising from this on the 15th,
although I
didn't identify the cause until the 17th, at which point I asked
it in #Net::Twitter and Marc Mims brought the question here under the subject line "Bug? Updates > 140 characters return success with prior update payload". See the discussion under that thread for more on
but the overall upshot is:

- This is an intentional (if poorly-announced) change, not a bug.
- Status updates are known to be getting silently rejected in this manner both due to exceeding 140 characters and due to violation of
  the expanded "no duplicates" policy.
- Twitter has not stated whether there are any additional
beyond those two cases in which updates will be silently rejected. - Twitter has not stated any plans regarding adding an indicator for
  when a "200 OK" status update has, in fact, been rejected.

I am attempting to compensate for this change by checking the
status ID against the previous highest-seen ID to determine whether
status returned with the "200 OK" response is a new one or the user's pre-existing status. This seems to work, but does not indicate the
reason for the silent failure, so I can't report the cause to my
Andy Freeman has mentioned that, in the case of rejection due to
duplication, this is also unsatisfactory in that it does not allow
to identify the original status which was duplicated.

Dave Sherohman

AJ Chen, PhD
Chair, Semantic Web SIG, sdforum.orghttp://web2express.org
Palo Alto, CA

AJ Chen, PhD
Chair, Semantic Web SIG, sdforum.orghttp://web2express.org
Palo Alto, CA

Reply via email to