@dom68 @OderWat The use case is pretty simple: I just need to upload a docx
file to Google Drive from a CLI tool. The tool was originally written in Python
with PyDrive, so the whole API interaction layer was hidden.
I also thought about keeping the server running the whole time, but this looks
I thought the same @dom96 but I did not post it because obviously a running
server is one attack vector more in a system if you otherwise can be "closed".
My [Hubic2SwiftGate](https://github.com/oderwat/hubic2swiftgate) is a program
which does something similar:
The the whole server is used to
What sort of application are you planning to use this in?
I have a feeling that it would make more sense to simply keep the server
running instead of shutting it down and restarting it for each request.
> Are you sure you need both a server and a client for this? Yep. Here's the
> Google API auth routine:
1\. Have a server running on some host; this host should be provided to Google
during in the next step.
2\. Generate a URL to the user consent form and let the user open it.
3\. When the use
> Thanks for the suggestion, but I'd rather not do it this way, because the API
> will suffer. When I call getAccessCode from an external module, I'm expecting
> to get the access code in return, not a Future that should be awaited on. So,
> one way or the other, I need a regular function return
> Could you please elaborate a bit on that? I don't mind doing something like
> waitFor acceptRequest. Is there a ready-to-use proc for that, or do you mean
> I should implement it by reading from socket?
My example relies on a future, and
[waitFor](https://github.com/nim-lang/Nim/blob/master/l
> Is it actually supposed to be a server rather than a client?
It's supposed to be both: receive a request, send a request to another host,
and receive the response.
> You can of course not use async,
In fact, that would be the thing I need. I don't mind blocking while waiting
for responses. B
Here's a pattern that hopefully satisfies your needs:
import asyncnet, asyncdispatch
proc doStuff(): Future[string] =
var retFut = newFuture[string]("asynctest.doStuff")
var server = newAsyncSocket()
server.bindAddr(Port(12345))
serve
Thanks for the suggestion, but I'd rather not do it this way, because the API
will suffer. When I call getAccessCode from an external module, I'm expecting
to get the access code in return, not a Future that should be awaited on. So,
one way or the other, I need a regular function returning a re
You could instead return a `Future[string]` from `getAccessCode`, basically
turn the whole thing into an async proc.
10 matches
Mail list logo