Clearly Twitter should not have changed the behavior without
notification.
However, >= is the only mechanism which is guaranteed not to drop
messages; it doesn't matter if we're talking milliseconds or seconds,
there is always going to be the possibility of two messages with the
same date stamp. So long as two messages can arrive in the same clock
instant, but one before, and the other after, your query, time
checking is not going to work reliability. Your only options are to
risk getting the same message twice, or risk dropping a message.
As with a number of other argu////discussions on the list--this is
another difference between a system that uses queues or inboxes, and
one which uses database queries.
For this reason, the only time we call "since" is when we want a broad
swath of messages (e.g. everything since yesterday)". If we really
want "the most recent messages I have seen" we store the highest id
seen for each API call for a given user, and ask for ids greater than
that. Since that mechanism can potentially return the same message
via two different API calls, we still check for and toss duplicate
messages.
An interesting side discussion is whether any of the functionality
offered by a pure-database solution is in fact interesting to anyone.
(E.g. add a friend, get all of their old messages). If not, a queue
system would presumably offer a number of efficiencies.
Evan
--
Evan Weaver
~~ Robert.
Depends on the app, I think. I suspect desktop client users, and any
folks who aren't *expecting* to miss some content (like users with a
relatively small # of friends, which is the majority of Twitter
users), will be unhappy to lose a message. In such cases, I think it's
better to assume dupes will come through and ditch the ones you
already have.
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
I don't know about other people, but I will out-and-out abandon the "since" feature if it is decided
to show dupes. If I have to check for dupes anyway, I'm going to have to start tracking ids. And
if I'm having to tracking ids anyway, then what's the point of tracking dates, too?
It sounds like the "since" feature was a clever idea that's flat-out broke.
~~ Robert.
Good point, and I don't use "since" at all. I've thought about it just
to lower transfer sizes/Twitter load, but I doubt Spaz makes much diff
there 8)
> It sounds like the "since" feature was a clever idea that's flat-out broke.
Well, let's not go over the top here. I think it's still a good idea.
Maybe just needs a bit o' tweak.
Actually, if you were to abandon timestamps and have "since" mean "since id", that'd get you the
same functionality without the race condition.
~~ Robert.
> What tweak, though? Unless tweets are guarantied to have unique timestamps, you're going to be in
> this catch-22.
Perhaps not such a clever idea, then? 8)
> Actually, if you were to abandon timestamps and have "since" mean "since id", that'd get you the
> same functionality without the race condition.
There ya go.
And that's the better approach.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Optimization hinders evolution. --------------------------------------------
TTYtter does use since with a last ID#. There's a bit of glitchiness which
is mostly overcome with an ID database to keep "stuttering" to a minimum.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- The only thing to fear is fearlessness -- R. E. M. -------------------------
Got a link to TTYtter?
~~ Robert.
Surely; it's since_id.
http://twitter.com/statuses/friends_timeline.json?since_id=x
> Got a link to TTYtter?
http://www.floodgap.com/software/ttytter/
Hopefully a new version this week. Waiting to see what happens to rate limits
*cough*al3x?*cough*.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- "I adore my Commodore 64" --------------------------------------------------
Bleh. This doesn't seem to work for friends_timeline anymore. It *is*
documented for public_timeline, however, so I defer on this one with
apologies.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Why was I born with such contemporaries? -- Oscar Wilde --------------------
We would prefer to drop the "since" (the timestamp one) and only use
"since_id", but it seems like a lot of people use the timestamp
"since".
Evan
--
Evan Weaver
Whew! Thought I was going nuts there for a second. Thanks for the reply. :)
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- BOND THEME NOW PLAYING: "For Your Eyes Only" -------------------------------
Agreed, but in the meantime you can simply implement the functionality
yourself at a lower level, and know that you're code will keep working
when Twitter makes the change.
# 20 most recent IN LAST 24 HOURS
friends_timeline => {
_url => '/statuses/friends_timeline',
_type => 'GET',
_auth => REQUIRED,
_cost => 1,
_class => 'update',
id => OPTIONAL|OBSOLETE,
since => OPTIONAL,
page => OPTIONAL|UNAVAILABLE,
since_id => OPTIONAL|EXTENSION,
},
I added since_id as an extension. The code in the library API checks
everything returned and makes sure nothing is older (or equal to :-)
the since_id, and tosses the rest. Voila, it's supported via the API
until Twitter has a chance to fix it.
I'd like to remove the 24 hour constraint, too, btw. This would be a
permanent change. Instead it would be the same as web, which is
currently 1 week but soon will be upped to 1 month.
In general we're trying to converge web and API functionality, which
will include pagination at some point in the API methods.
Evan
--
Evan Weaver