Hi,
On Sun, May 5, 2013 at 10:20 PM, Jeff Schnitzer wrote:
> This has come up a number of times in the past. Timestamps are based on
> the clock on the server running your Python code. Google makes no official
> guarantees about clock skew in the cluster, although presumably they are
> all NTP s
This has come up a number of times in the past. Timestamps are based on the
clock on the server running your Python code. Google makes no official
guarantees about clock skew in the cluster, although presumably they are
all NTP synchronized. In practice, 30s of overlap is going to work 99.9% of
the
Hi again Vinny,
A related question about implementing pull updates. I would like to pull
only the updates since the previous pull, but if possible I would like to
avoid recording which updates have been delivered to each client.
How much can I trust the datastore timestamps (i.e. auto_now)? The h
Hi Vinny,
Essentially, if you want to push updates in less than a handful of seconds,
> use the channel API. For anything else, AJAX/JSONP pull updating is
> completely fine.
>
Thanks for your insight. In my case updates are relatively infrequent and
latency is not a big problem, so I guess I'll
Use PubNub :)
On Sunday, May 5, 2013 12:32:48 AM UTC+8, Pertti Kellomäki wrote:
>
> Hi all,
>
> I am building an app where users can post comments and the like, which
> should be pushed to selected other users in near real time. My current
> prototype uses the channel API and it is working fine
Hello Pertti,
Polling once a minute is quite slow, actually. You don't need the channel
API for updates that are infrequent as once/minute.The Channel API is meant
for realtime communications (i.e. seconds/less-than-second difference
between messages) - for example, if you were implementing a c
