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. > > Dewald > > 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. > I > > 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 > good > > 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 > in > > your application code. > > -aj > > > > > > > > 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 > the > > > > > 13th and the 16th that is now causing all my 140+ character posts > to > > > > > be rejected by the API. > > > > > Also a side note is that the api is not returning errors, they > return > > > > > proper responses however they are the proper response for the > current > > > > > status of the account, not the new status that was just attempted > to > > > > > 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 > about > > > > 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 > it, > > > > 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 > circumstances > > > > 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 > returned > > > > status ID against the previous highest-seen ID to determine whether > the > > > > 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 > users. > > > > Andy Freeman has mentioned that, in the case of rejection due to > > > > duplication, this is also unsatisfactory in that it does not allow > him > > > > 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.org http://web2express.org Palo Alto, CA
