(Re. discussion at the Desktop Summit:) I think polling this is the best we can hope to get for notification support for changes to documents.

Google Drive API for it: https://developers.google.com/drive/v2/reference/changes

Although related, the Changes API won't exactly let us implement notifications. For that we need the Channels API:
https://developers.google.com/drive/v2/reference/files/watch
https://developers.google.com/drive/v2/reference/channels

(In reply to Debarshi Ray from comment #3)
> Although related, the Changes API won't exactly let us implement
> notifications. For that we need the Channels API:
> https://developers.google.com/drive/v2/reference/files/watch
> https://developers.google.com/drive/v2/reference/channels

I was playing with the Channels API using the API Explorer today. The various watch methods (Changes:watch, Files:watch) are supposed to give us a Channel, but I don't think we can make it work with a desktop client because they are based on webhooks [1]

For example, this request:

POST https://www.googleapis.com/drive/v2/changes/watch?key={YOUR_API_KEY}

{
 "id": "gnome:foo",
 "resourceId": "1xLBrDLPPd3wVC-lk3EJrjRRqFLMWsZgBjzWTump0o5I",
 "type": "web_hook",
 "payload": true,
 "address": "https://www.gnome.org/foo"
}

... fails with:

Cache-Control:  private, max-age=0
Content-Encoding:  gzip
Content-Length:  176
Content-Type:  application/json; charset=UTF-8
Date:  Mon, 25 Jul 2016 14:53:49 GMT
Expires:  Mon, 25 Jul 2016 14:53:49 GMT
Server:  GSE
Vary:  Origin, X-Origin
WWW-Authenticate:  Bearer realm="https://accounts.google.com/", error=invalid_token

{
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "push.webhookUrlUnauthorized",
    "message": "Unauthorized WebHook callback channel: https://www.gnome.org/foo"
   }
  ],
  "code": 401,
  "message": "Unauthorized WebHook callback channel: https://www.gnome.org/foo"
 }
}

[1] https://en.wikipedia.org/wiki/Webhook

(In reply to Debarshi Ray from comment #4)
> I was playing with the Channels API using the API Explorer today. The
> various watch methods (Changes:watch, Files:watch) are supposed to give us a
> Channel, but I don't think we can make it work with a desktop client because
> they are based on webhooks [1]

Even if we can't have push notifications via Channels, it could still be worth supporting the Changes API. We can avoid repeatedly downloading the entire metadata while polling a large enough Drive. Unless the contents of the Drive is rapidly changing, this should be more optimal.

(In reply to Debarshi Ray from comment #4)
> (In reply to Debarshi Ray from comment #3)
> > Although related, the Changes API won't exactly let us implement
> > notifications. For that we need the Channels API:
> > https://developers.google.com/drive/v2/reference/files/watch
> > https://developers.google.com/drive/v2/reference/channels
> 
> I was playing with the Channels API using the API Explorer today. The
> various watch methods (Changes:watch, Files:watch) are supposed to give us a
> Channel, but I don't think we can make it work with a desktop client because
> they are based on webhooks [1]

I think you need to add gnome.org to the list of authorised domains in the Google API control panel to get that webhook call to work:

http://stackoverflow.com/a/24588802/2931197

However, unless we build a push notifications service from gnome.org to every desktop using GNOME Documents, this approach won't work, as you say.

(In reply to Debarshi Ray from comment #5)
> (In reply to Debarshi Ray from comment #4)
> > I was playing with the Channels API using the API Explorer today. The
> > various watch methods (Changes:watch, Files:watch) are supposed to give us a
> > Channel, but I don't think we can make it work with a desktop client because
> > they are based on webhooks [1]
> 
> Even if we can't have push notifications via Channels, it could still be
> worth supporting the Changes API. We can avoid repeatedly downloading the
> entire metadata while polling a large enough Drive. Unless the contents of
> the Drive is rapidly changing, this should be more optimal.

Definitely worth supporting the Changes API. Are you going to get time to work on it?

It is not based on Changes API and anyway I think we should build the cache incrementally and we can use Changes API in the future for proper invalidation. I wanted to make just a simple improvement initially based on etags provided by Google. Unfortunately, etags change per each query regardless of actually changes, so I ended up with this bigger patch. Rishi, what do you think?

Sorry, this comment was for Bug 771390.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgdata/issues/6.