#bridgy 2017-03-23

2017-03-23 UTC
ben_thatmust, snarfed, [kevinmarks], mblaney and [eddie] joined the channel
#
aaronpk how far back does bridgy poll for twitter responses?
#
aaronpk like how many tweets back does it look?
#
aaronpk or is the question how long does it keep looking at a single tweet for responses?
snarfed joined the channel
#
aaronpk did just RTFM and didn't see anything
#
snarfed good q!
#
snarfed double checking, but very roughly, it looks at your last 50 "posts"
#
snarfed i kinda deliberately don't document this or provide exact numbers since i don't want to commit to them
#
snarfed slightly related: https://github.com/snarfed/bridgy/issues/579
snarfed joined the channel
#
snarfed oh except heh, i actually did document it :P https://brid.gy/about#50%20most%20recent
#
aaronpk ah heh
#
aaronpk i was sketching out my polling plans for ownyourswarm and i came to a very different approach i am realizing
#
aaronpk tho it might only be applicable to ownyourswarm because of specific behavior on swarm
#
aaronpk (people don't often comment or like super old posts at all)
#
aaronpk my plan was to maintain a separate polling schedule for each checkin
#
snarfed huh wow, i wonder about scaling. how long would you poll each checkin?
#
aaronpk my plan was to do backoff at the following intervals, and restart the schedule if any changes were detected: 15,30,60,120,300,600,1800,3600,14400,86400
#
snarfed ah ok, makes sense
#
snarfed so swarm doesn't have a way to get checkins and responses (mentions coins etc) in batch?
#
aaronpk (those are seconds)
#
aaronpk well the coins and photos are sort of part of the checkin
#
snarfed also do you maybe also want 1w and 1 mo polls? max 1d seems short...but you know swarm better than me
#
snarfed right, i mean, is there no way to say, get me my last N checkins?
#
aaronpk i should probably add 1 week and 1 month
#
aaronpk hm yeah there is an endpoint to get the last N checkins
#
aaronpk and that does seem to include photos and likes and comments
#
aaronpk not coins, but that's an easy one to special-case
#
snarfed yeah, then your poll tasks scale with users, not checkins
#
snarfed many silos at least include at least a count of each kind of response (eg coins), if not the coins themselves, which you can cache so you know whether there are new ones to fetch
#
aaronpk it appears foursquare returns 'compact' checkin objects in the list view, which doesn't include the 'score' (coins)
#
aaronpk actually no, this is just not consistent
#
aaronpk https://developer.foursquare.com/docs/responses/checkin
#
aaronpk also from https://developer.foursquare.com/docs/users/checkins "We highly discourage developers from polling this endpoint to learn of new check-ins or to keep their users' check-in history synced. Using the real-time API is a much better solution."
#
aaronpk well it seems like if i can make one request to get the user's latest 250 checkins, including all the comments and likes, then i just end up doing a bunch of processing on my side each time i hit that endpoint, which is cheap
snarfed joined the channel
#
snarfed exactly! that's what bridgy generally does.
[cleverdevil] joined the channel
#
snarfed plus maybe n coin fetches, or less than n if you get counts or last coin timestamp or something
#
aaronpk coins are easy because they're available almost instantly
#
aaronpk if i wait 10 seconds, they'll be there, and no new ones will be added unless a photo is added later
#
aaronpk photo polling is a little trickier, but i think that's where my backoff polling schedule comes in.
#
aaronpk when you check in, there is no photoat first, the photo appears after the app has uploaded it and attached it to the photo. however i don't know exactly when that will be, so i was thinking of the backoff strategy to find it
#
aaronpk s/to the photo/to the checkin
#
aaronpk you are probably right that i should treat backfeed separately though
[kevinmarks], snarfed, snarfed1, ben_thatmustbeme, [eddie], [dgold] and mblaney joined the channel