/posts?since=cursor:3 seems to be missing a time parameter

[imaginator]

[rodrigods]

cc: @jkarneges

[jkarneges]

What do you mean a time parameter?

[lloydwatkin]

We believe that cursor:3 is not the correct thing to be sending and there should potentially be a timestamp instead? We may have been wrong but this looked weird to us.

[jkarneges]

Ah, no, this is intentional and ideal for the purpose of the notifications/posts endpoint. Before I started working on this code, this endpoint did not accept any parameters at all. I added the "since" parameter with cursor value in order to ensure reliable delivery, and an integer sequence is more robust than a timestamp.

[lloydwatkin]

Closed then. Thanks for the update @jkarneges

[imaginator]

I was thinking about this (had to wait a long time at the barber yesterday). Does the server store a previous cursor value? Could someone do an explain-me-like-I'm-five on how this works. #confused.

[jkarneges]

Yes. Basically the /notifications/posts endpoint has a per-user queue. If you query without the 'since' parameter, then the server returns no data along with the latest cursor value for the user's queue. If you query with a 'since' parameter, then you get all items in the user's queue after the provided cursor, or if there are no items after it then the server will long poll until an item is available.

The webclient bootstraps itself by first querying this endpoint without a since parameter to obtain the most recent cursor value. From that point on it provides a since parameter.

One issue with the current server implementation is that it maintains an indefinitely long queue of items. That is, I believe you can query as far back as the start of the session. We should eventually have old items expire.

Hope that clears up how it works.

[imaginator]

Thanks for the explanation.

Some edge cases:

• how this works when the user is work when a user is on a browser and mobile at different times?
• is the cursor persistent on the API server? (we restart a lot)
• what happens when there is more than one server?

On 4 July 2013 20:42, Justin Karneges notifications@github.com wrote:

Yes. Basically the /notifications/posts endpoint has a per-user queue. If you query without the 'since' parameter, then the server returns no data along with the latest cursor value for the user's queue. If you query with a 'since' parameter, then you get all items in the user's queue after the provided cursor, or if there are no items after it then the server will long poll until an item is available.

The webclient bootstraps itself by first querying this endpoint without a since parameter to obtain the most recent cursor value. From that point on it provides a since parameter.

One issue with the current server implementation is that it maintains an indefinitely long queue of items. That is, I believe you can query as far back as the start of the session. We should eventually have old items expire.

Hope that clears up how it works.

— Reply to this email directly or view it on GitHubhttps://github.com/buddycloud/webclient/issues/247#issuecomment-20489540 .

Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP

[jkarneges]

I should clarify that there isn't really any kind of independently stored cursor value. There is only the user's message queue, and the client can ask for a cursor value that points to the last queue item. So having multiple clients sharing the same XMPP session (and therefore message queue) is fine. They won't collide or anything, as the server is not storing anything specific to client instances. If the API server is restarted, then the session and message queue are gone and you want the cursor to start over from the beginning. If a client attempts to make a request using a stale cursor, I believe it will end up resetting to the start (though I've not tested this).

The current endpoint as it is written will not work with multiple servers, as each server would have its own XMPP session and message queue with different cursoring. Meaning, a cursor used from one server would most likely do the wrong thing if directed at a different server. You'd need to sticky route.

Long term, I think we should change the realtime API to be less dependent on the notion of a user session, but for now it gets the job done.