PresentMonService.exe usage model and backward compatibility

[AlexUnwinder]

Can you please comment your view of PresentMonService.exe usage model? Do you see it as a helper service for your internal overlay/CLI applications only or did you plan it as some unified interface and expect third party applications to be developed as PresentMonService.exe clients too? If so, is backward compatibility for PresentMonAPI.dll planned, so future versions of service can be expected to be backward compatible with previous versions of PresentMonAPI.dll?
I'm asking because currently I integrated PresentMon support into RTSS as PresentMonService.exe client, but I'm still not sure if it was right way to go.

[planetchili]

Thank you for your interest and your inquiry. We do anticipate and encourage 3rd party applications interacting with PresentMon Service. We also will guarantee backwards compatibility of the API, including compatibility between older versions of the .dll with newer versions of the service. However, one caveat is that the API of the current beta (pre-V1.0) is not stable and very likely will change. After the V1.0 release the interface will be locked and backwards compatibility will be guaranteed for future versions.

The current thinking is we would like to shift to a dynamic API that supports querying/enumerating all available metrics programmatically together with their respective metadata, and dynamically specifying loadouts for polling (rather than having a static set of functions, each returning a collection of pre-defined metrics as a static structure). This will enable optimizations, will make certain workflows easier to implement (such as a client presenting all available metrics to an end user for selection), and will enable some forwards compatibility.

We are also considering maintaining something similar to the current static API as a light wrapper layer above the planned dynamic one. For developers with simple workflows and requirements, the current API will likely be easier to work with since it doesn't require dynamic structures and extra enumeration steps. We will need to undertake the work on the new API before we have a clear picture of how much the simple API wrapper will need to differ from the current API, but it is likely that we can maintain high or perhaps even 100% code compatibility with the current interface endpoints.

Another issue just came to mind: .dll compatibility will be ensured from V1.0+, but will almost certainly break between current beta and V1.0. This is due to the fact that we plan on a large change to the current IPC mechanism, which will almost certainly entail protocol changes.

Feel free to let us know your comments, ideas, and preferences related to the above and we will take them into consideration moving forward!

[AlexUnwinder]

Excellent, thanks! That's exactly what I was hoping to hear. It won't be a problem to update the clients a few times while the service is travelling to v1.0.