PAL import improvement

[McCrea]

As it stands, we have one PAL its files live in the API directory under 'app' distinguished from the API layer only by filename prefixes. This situation needs to change in order to fully utilise the platform-abstracted architecture and make porting/configuring the application as simple as possible.
I suggest that two core modifications be made:

• Relocate PAL files: As the PAL is a separate layer to the API layer there should be a PAL directory within the 'app' directory. This PAL directory would contain a subdirectory per platform supported; if the application was packaged for a specific platform then there may only be a single subdirectory, but this would support disambiguation of 'PAL' within the directory structure and imports from code. e.g. the datastore PAL for Google App Engine would be located in app/PAL/GAE/Datastore.py and could be imported using 'import app.PAL.GAE.Datastore.py'.
• Provide a method for choosing which PAL to import. It may be preferable to allow granularity so that a particular PAL could be chosen for each API - whilst it is unlikely that a single deployment would run a single request across multiple platforms some platforms may provide multiple PALs for use by a single API - for instance two different Datastore PALs which utilised different underlying storage technologies. The method for selecting the PAL files to use should probably be in the form of a single configuration file to ease pre-deployment configuration.

[notchris1]

I like this, does this mean though that the calling api's import a specific pal ie .GAE. , .EC2., ect, or is there going to be a transitional layer, some pal genericiser, that gets changed when the app is configured, or will the API just be modified?

[McCrea]

Since the API doesn't need to know what's below it, I'd prefer to have a generic import interface.
Ideally the import would look something like:
from Platform import Files, Permissions
And the logic under Platform would deal with looking up which PAL to actually import.

[McCrea]

I forgot to mention above, but I also think that we should define interfaces which PALs implement - basically as a way of defining what a PAL needs to look like for it to be compatible with the API layer.
Since Python uses duck typing this isn't strictly necessary, and since Python is Python there are a few different ways of doing it. This means that some thought should be given to the approach taken.