Were working to address these issues and thank everyone. gPodder is a service that allows the user to download free audio and video content (Podcasts) to watch on their computer or on the go.
#Gpodder api serial
A “safer” way would be to provide a serial event number where the client says “last event I received is 12345, send me everything from event 12346” but this means a greater amount of smarts on the client, a more complex API, and more complexity on the server to assign sequential event IDs on the server. Some of the 500s persist when using the web client, but dont seem to affect API-based requests. So, whatever I do, it’s probably safer for clients to assume that they may receive duplicate items if they’re being retrieved based on the time.
The only problem I can see here is that because a lot can happen at the same time, if the client relies on the timestamp being the exact point that data is read, it’s possible for a parallel write to have a timestamp before the read but is not yet visible to the read due to the way RDBMS transaction isolation works… only the matter of milliseconds, but still possible. Yep, good idea - I could return the server timestamp in all API responses. (Also, but you might label this ‘out of scope’, it would be cool to get data on which feeds are popular, so that relational recommendations (‘those subscribed to x are subscribed to y’) could be presented for example directly in AntennaPod for those that sync with your service.) My AntennaPod installation and the entry are then ‘conflicting’
#Gpodder api update
However, the person owning/hosting the feed forgot to update their entry on, which thus stays xyz.com/rss. Because of the redirect AntennaPod updates the feed it follows. I as an AntennaPod user follow xyz.com/rss, and the feed changes address (to abc.com/rss) with a nice 301/308 redirect on the server. I’m asking because of the following scenario:
0 kommentar(er)
