nt and ot parameters seem not to work about api HOT 26 CLOSED

Should be working, I have passing tests regarding this. Could you please provide specific request you are making?

from api.

I tried https://theoldreader.com/reader/api/0/stream/contents?output=json&ck=1374473235813&s=user%2F-%2Fstate%2Fcom.google%2Freading-list&xt=user/-/state/com.google/read&n=1000&r=n&ot=1374473231
And it always shows me all items again instead of items with dates newer then 1374473231.

I want to have newest first and and newer than 1374473231.

Note: in your api nt means older than, and ot means newer than. should it be reversed?

from api.

We are trying to mimic Google Reader API so parameters naming has been taken from there.
The point is that ot is working only when r=o, as described in documentation.

from api.

That's not true. ot is also supported by r=n. There is no nt parameter in Google Reader. Also in Google Reader n means newest first and o means oldest first. In your implementation I think it is reversed.

Could you pls look into the link.
http://blog.martindoms.com/2009/10/16/using-the-google-reader-api-part-2/

gReader was working like this for many years.

from api.

The problem is that you cannot get items newer than a specific time with sorting newrst first. That means that the users have to download all unread items again and again. It would slow down your server.

from api.

Regarding this doc (https://code.google.com/p/google-reader-api/wiki/ApiStreamItemsIds) Google has both nt and ot parameters, and we have correct implementation. Conditions regarding when to apply this parameters were taken from discussion with other developers, see #7. Also, gReader seems to be working fine using our API.

from api.

Ok nt might be supported. But why doesn't ot work with r=n? I think there is no restriction on for ot.
The problem I am facing is that gReader always download all items again. It does not recognize ot.

from api.

The problem is that client might not get all unread items when newest is first and ot is passed.

from api.

Shouldn't it work like this. That the problem of the client. It depends on what client is asking.
ot (newer than) is used for incremental sync. On client side ot is the last sync time. That means that it only fetches all items with date larger than ot. If you want all items ot would be 0 (or not available)

e.g. you sync all unread items on time "1". now it is time "10". setting ot to 1 would fetch all unread items that is newer than "1". Next sync ot would be "10". That way you would get all unread items and you don't have to sync all items that is older than "1". it used to work like this on Google Reader.

from api.

Your point seems legit. But unfortunately it may break existing clients. @cbliu, @evgenynacu, could you please help?

from api.

It's your system. I just want to point out.
With the change it could reduce your traffic. Also client syncing would be faster.

from api.

Hi @krasnoukhov,

I am seeing the issue again. ot (newer than) does not work with r=n (newest first)
I think it was fixed but right now I experience it again.

from api.

Hey @noinnion, we didn't touch these sorting/filtering options since we had latest discussion. I'm not sure why you noticed this today.
So, back to problem. As I understand, you want to use this combination (ot + r=n) in order to retrieve new unread item ids from some point in time?

from api.

Yes, that's right.
I think that the problem already exists for a while. I just recognized it today.
Using r=n ignores ot. It was working since you fixed it last time.

from api.

Ok, so you are using these parameters only when retrieving unread ids?

from api.

I use it for https://theoldreader.com/reader/api/0/stream/contents.

from api.

Are you requesting only unread post contents, or just everything?

from api.

For Reading-list i request only unread post.
For specific streams (tag / feed) I request all items with a limit.

from api.

Ok, I see. The main reason why I can't enable ot parameter to also work with r=n is that in this case there is a chance that you'll miss some items.

from api.

On which case do I miss items? and why?

from api.

There is a case when post is already fetched but not yet propagated to reading lists in database. Propagation process might take several minutes to complete, and some users will never see this post.

from api.

what's the difference when I use r=o and ot? isn't it the same case?
r=o + ot works

from api.

Actually yes, there's a chance to miss some posts even when using reverse sorting.
Ok, I disabled conditions on ot/nt parameters. Let's try using it for a week, and if there's no complains I can leave it this way and update doc.

from api.

great, thank you

from api.

Can you please also change "client" param to something more clear like "greader" so we'll be able to monitor requests in a better way?

from api.

Ok, the change will be in v3.5.4
On Dec 30, 2013 2:25 PM, "Dmitry Krasnoukhov" [email protected]
wrote:

Can you please also change "client" param to something more clear like
"greader" so we'll be able to monitor requests in a better way?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-31345516
.

from api.