22: Making a sub-package for server functions #25
Conversation
…ampus/pprl_toolkit into 22-server-functions
| Encrypted data encryption key (used to encrypt the data). | ||
| """ | ||
|
|
||
| bucket = store.get_bucket(f"{party}-bucket") |
There was a problem hiding this comment.
Is this hard-coded? Does it conflict with the advice in the tutorial about creating hashed bucket names?
There was a problem hiding this comment.
No, because the users don't create the bucket themselves. You can see this naming structure in the party set-up script.
|
|
||
| credentials = create_impersonation_credentials(party, operator) | ||
| store = storage.Client(credentials=credentials) | ||
| bucket = store.get_bucket(f"{party}-bucket") |
There was a problem hiding this comment.
Same question about hard-coding
| @@ -0,0 +1,46 @@ | |||
| """Functions for performing matching locally.""" | |||
There was a problem hiding this comment.
To my taste, the functions in 'local.py' are too short and not used enough times to be worth wrapping up into a separate module. There's a readability trade-off: on the one hand it's tidy, but on the other hand it becomes much less linear; it requires the reader to search around to follow the underlying logic. I'd negotiate this trade-off differently, but you have the final say.
There was a problem hiding this comment.
I can see that for sure.
My view is that because the cloud functions get taken out (and they should) these should as well. Creating a module for each behaviour creates consistency, which is no bad thing.
Also, if we don't take them out, then the server script has stuff in it that isn't relevant for most users should they go delving into it.
Fixes #22