Open McCrea opened 10 years ago
I agree with all of these, the split seems logical, the users api I creates pertains to the authentication cleanup (users PAL) to improve consistency before major rewrites, however this has not yet started, so I could migrate the purpose of this, i would be Interested in being involved In this section
Also see #167
I think the users API should stay separate to authentication, but the API (and underlying storage) need some work in order to facilitate multiple authentication methods. If we're doing an API overhaul, might as well fit that in.
I agree it should be seperate, but at the moment the authentication is known as users PAL, hence the users API. Users is adopted from googles naming of authentication. I am not suggesting combining them.
Ah, okay. Perhaps we should call it the 'Authentication PAL' - we needn't be tied to Google's naming conventions. The way I see it, such a PAL would actually contain little-to-no authentication logic - it'd just be responsible for loading other libraries which would actually contain the auth logic and proxying the results to into user data storage calls. That way we could support multiple authentication methods.
I agree, perhaps spin up a new thread.
I've been working on this when I've had spare time (read 'infrequently') though haven't pushed anything yet since it's all sitting in a spec-only or partially-implemented state. I'll do my best to push my proposed API spec in some form in the near future.
The approach I am taking involves the following:
So far I've done the following:
This sounds perfect, is there any documentation of specifics at this stage?
Short answer: not yet Slightly longer answer: I've written stubs for a fair bit of the functionality so that I can work on the higher layers without implementing the lower layers first. I'll try to document those stubs and push them as a priority.
Excellent, it will be nice to generate some progress on ksf. It also is a good jumping off point for larger changes.
On 16 Jul 2014, at 21:10, Jack McCrea notifications@github.com wrote:
Short answer: not yet Slightly longer answer: I've written stubs for a fair bit of the functionality so that I can work on the higher layers without implementing the lower layers first. I'll try to document those stubs and push them as a priority.
— Reply to this email directly or view it on GitHub.
I agree. I'm working on these changes so that it will be easy to work on a hierarchical gating UI. I've got ideas for a lazy-preloading panel which makes it appear that the client has grabbed information about every file a user can access when in reality it's only grabbed a small number. But that's a story for another thread.
APIPermissions, I don't like it. These days it does more than just permissions and that isn't really right.
I propose it be split into three APIs:
They might use some common PAL components for actual storage, but the methods for reading/writing should probably be separated out properly. This would also be a good opportunity to enhance how we use the NDB datastore in the GAE PAL; I propose the following:
I think it would be prudent to start with the files API in order to facilitate the development of efficient hierarchical gate display. I believe there's already a branch created by @Ahemagain for the users API, so that just leaves the permissions API. Once the APIs are done, we'll need to build another utility layer on top of the APIs which link them together for things which require interaction with multiple APIs (such as getting all the files a user has permission to see). Thoughts?