use oauth2 lib and remove deferred dependency #14
Conversation
Use oauth2 library instead of manual managing of tokens. http calls are done through it so we don't use deferred.el anymore.
|
It's probably worth noting somewhere that |
org-gcal.el
Outdated
|
|
||
| (defun org-gcal-end-date (time) | ||
| (if (< 11 (length time)) | ||
| `("end" ("dateTime" . nil) ("date" . nil)) |
There was a problem hiding this comment.
This should have ("dateTime" . ,time), just like org-gcal-start-date above.
Entrypoint to creating an event in a google calendar without relying on current-file, location or anything
|
I've been testing this out a little - it seems that this code doesn't refresh the token properly when the access token expires - I haven't investigated to figure out why yet. It's possible that you need to manually reauthorize whenever you receive a 401 from the Google Calendar API. See also https://developers.google.com/calendar/v3/errors. |
|
yes, I'm working on that also. It looks like oauth2.el defadvice is not triggering. Things I'm about to try are:
|
|
it looks like using |
|
from And yes, the async version doesn't get any extra var than the ones defined in It's not easy to write a hack for this to work either. I'll be looking for alternative ways to keep asynchronicity and code reuse (thinking of |
On kidd/org-gcal.el#14, some difficulties have been encountered with the oauth2 branch, and refresh tokens don't work properly on this branch, so I'm reverting back to the rebind branch for now.
oauth automatic token-refreshing does not work with asynconous url-retrieve. That happens because dynamic bindings are not held through the request (except a few chosen ones `url-http'). This commit comes over the synchronous + refresh problem by using multiple threads in a synchronous way.
org-gcal.el
Outdated
| (org-gcal--add-time))) | ||
| 'rgc-cb | ||
| (list cal skip-export))))))) | ||
| (make-thread (lambda () |
There was a problem hiding this comment.
Emacs 26.1 only ?
Just an idea, but how about carrying extra variables as
symbol-plist of calendar-id or something ?
There was a problem hiding this comment.
nah, the make-thread was just a crazy test. I guess this branch is turning into an 'experimental' branch. sorry for the confusion.
I don't fully get you on the plist for the calendar-id. What would it solve?
The remaining problem here is that:
- oauth2.el doesn't refresh the token automatically if used asynchronously.
- using synchronous requests works, but for multiple calendars it can become a little sluggish.
- as an "extra" annoyance, oauth2 uses plstore, and it looks like you have to enter the passphrase to decrypt the data of the tokens way to often and way too many times. This gives a shitty experience also.
I've been looking at google-contacts.el, calfw.el, and other similar packages and all of them have hacks around those. I'll revert the thread thing, but not sure what's the next thing to try :(. Feel free to throw ideas in.
|
Thu Jul 26 18:03:24 BST 2018 Hi, Will the move to Looking forward to this updated version being pushed to |
|
@rprimus , when using oauth2.el, tokens are stored using plstore. Until we find a suitable solution of each of those, this branch won't be merged. |
Lifting the call to `org-gcal-auth' was a bad idea because when the token expired, we were sending the expired token for each calendar we want to synchronize. Now the first one that gets the expired token asks for renewal, and next ones use the renewed token.
|
When this is mature I would appreciate a buzz to test this branch on windows. |
|
This is obsolete - see #191 for continuing progress here. |
Use oauth2 library instead of manual managing of tokens. http calls
are done through it so we don't use deferred.el anymore.