Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactoring: App hash should return pool ID if the app belongs to pool #41

Open
vjekob opened this issue Jun 19, 2022 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@vjekob
Copy link
Owner

vjekob commented Jun 19, 2022

Ninja uses app hash to access back-end features. For the back-end, the hash identifies an app. App pools "hijack" this feature by simply replacing the app ID with app pool ID. Since the back-end has no way to tell an app from a pool (and since it doesn't really care if it's an app or a pool) it performs all operations correctly for both apps and pools.

However, in the front end, there is a lot of fumbling around checking if an app is in a pool in a lot of unnecessary places.

Proposed change is this: get property for hash in ALApp class should return app ID hash if it's an app, or app pool ID if it's an app pool. All places where app pool ID is accessed directly or taken into account for some choices should be refactored. The reason is that there are a lot of places where explicit checking of pool is done, and those places don't really care about pools - they merely care about retrieving correct hash to work on. In great majority of these operations, it's the pool ID that should be used anyway.

This refactoring will reduce the number of places where app pool is worked on explicitly.

However, it carries a big risk of breaking some existing features, so that's why this task here, rather than a simple TODO in the code. This needs to be handled very carefully.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant