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.
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
ALAppclass 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.