Customers upgrading to LiveCompare 3.7 will see public and private used in a couple of places:
The two “features” are completely independent. Let me deal with them separately.
We re-organized LiveCompare’s userdata storage to improve performance. When everything was lumped into a single folder we observed a 2%-5% CPU burn by IIS as it tracked every change LiveCompare made to userdata.
Many types of userdata are managed by LiveCompare, but only a few need to be accessed via a browser and thus need to be visible to IIS. One key type is reports. Reports are accessed via a user’s browser and thus must be visible to IIS.
The public/private folder names mean simply that:
Probably because of the names we chose and the public/private setting on XDSs, we’ve observed customers moving LiveCompare’s registration of XDSs from the public to private userdata folder. In hindsight perhaps better names for the sub-folders would have been:
I'm not convinced that we should rename the folders again.
This setting has absolutely nothing to do with the public/private userdata reorganization. The setting controls whether the contents of an XDS are accessible via a REST API (public) or not (private). By default all XDSs are private.
We added the REST API to make it easier for external applications – say a consolidated executive dashboard – to access LiveCompare-produced information without all the messing about with the web services API.
In hindsight we could have labelled the setting better. Perhaps:
In fact I like this so much we've changed it for the upcoming LiveCompare 3.7R3 release:
From our helpdesk database I see several things: