PMA.slidebox requires PMA.core to serve slides:

• PMA.core reads slides (typically whole slide images or WSIs for short) and handles user access.
• PMA.slidebox runs on top of PMA.core and is responsible for content presentation.

A couple of tasks need to be performed to make this interaction go smooth:

We need to tell PMA.core our slides live. You do this by creating a root-directory.

Next, you create a mounting point that tells PMA.core where the slides’ files are actually stored.

Slides can be stored in a folder on the hard disk, but a mounting pointing point can also be in Microsoft Azure , or refer to an Amazon S3 bucket.

Not all users have access to PMA.core. You do (obviously) when you go and create new root-directories.

PMA.slidebox requires a PMA.core user account to be able to retrieve content from it. Therefore, it is recommended that you create a separate PMA.core account for each public PMA.slidebox portal. In our licensing model, we refer to this kind of user accounts as service accounts. A service account is a concept; it's not something that you can explicitly specify in the PMA.core user interface. What you should do, however, is define the PMA.core user account with the Administrative flag set to False.

PMA.slidebox re-uses the same user account time and time again. This means that when you have two people John and Michael navigating to your PMA.slidebox website, you won't be able to distinguish who did what afterwards. There's no audit trailing or individual tracking with PMA.slidebox (if you do need that kind of granularity, refer to PMA.studio or PMA.control).

Once you have the service account and necessary root-directories defined, you go to the PMA.slidebox administrative panel to point it to PMA.core, and tell it which service account to use.

If you happen to want to use a PMA.core account that has the administrative flag set to True, you'll get a warning. It's not a requirement as such that you use a non-administrative account, but it is strongly recommended that you don't.