Code review comment for lp:~michihenning/unity-scopes-api/scope-cache-dir

OK, so the approach of looking for the scope's data dir and setting cache_directory() to the right value isn't going to work because the click install can't create the directory.

So, next best idea:

The registry can look for each scope in the manifests and parse the JSON to figure out what kind of scope it is looking at. Then it can go to $HOME/.local/unity-scopes and create the scope cache directory if it doesn't exist, with permission 0700. The registry adds the scope cache directory to the scope's metadata, which is available remotely.

On the scope side, during initialization of the run time, we go to the registry and grab the metadata, so cache_directory() can return the correct location.

Down-sides and questions:

- If no registry is running, we have to wait for the metadata() call to time out. Currently, the default timeout is 5 seconds, due to the slow emulator problem. This will probably break some tests, and will be inconvenient during development. The work-around would be to change the default registry timeout to something short, so things don't hang around all the time waiting to time out.

- I can look through /var/lib/apparmor/clicks for JSON files. In there, I find things such as

com.ubuntu.clock_clock_1.0.430.json
com.ubuntu.music_music_1.3.511.json

When I look at the clock one, I see:

{
    "policy_groups": [
        "calendar",
        "networking"
        ],
    "policy_version": 1.1
}

When I look at the music one, I see:

{
    "policy_version": 1.2,
    "template": "unconfined",
    "policy_groups": []
}

So, it's not clear to me what exactly I should be parsing ("template" or "policy_groups") to figure out whether a scope is leaf-net or aggregator/unconfined.

- We have scopes that come pre-installed, scopes installed by the OEM, plus scopes installed by the user(s). Is it sufficient to look through /var/lib/apparmor/clicks to guarantee that I won't be missing any scopes? For the approach I outlined above, I need to be sure that I find something for every local scope.

- I'm questioning the wisdom of what I suggested above. It seems that the registry is forced to do a lot more than it should have to just so it can let a scope know what its writable tmp dir is. Isn't this something that should somehow be available via an apparmor call? Or should there be a way for click to be able to create the directory in the right place?

- There are potentially many cache and settings directories for a single scope (one for each user). When a new user is added to the device, who should create the cache dir and settings dir?

My apologies for all the questions, but it seems that I don't have all the pieces of the puzzle yet, so I don't want to rush and implement something only to have it fall over for some reason I don't know about. I'd appreciate any and all feedback!