Hello,
using Ajax solves the issue of not refreshing the page, so you can reduce the communication to just the data values, but under normal conditions, it still requires that the activity (requests) come from the client side. When you start mentioning SubscribeMultipleItems, you are attempting to turn this model around - with this method, there is an activity that comes "from within" the componen, but the main issue not in how to subscribe, but what to do when the update arrives. You cannot have the Web server send the data to the browse when the server wants. The only way I know about to simulate this would be with something called "long polling", wher basically the Web service that processes the AJAX requests would block until the data becomes available, and the requests will be reissued immediately after such response is received, but currently we do not provide a code for "plumbing" this together.
But I think your main concern and main intent was to prevent the unnecessary OPC reads. If so, there is absolutely no need to use SubscribeMultipleItems. The QuickOPC is designed in such a way that internally it detects a repeating pattern of ReadXXXX calls, and creates, updates and removs OPC subscriptions as needed. When you call ReadXXXX, if the "recent enough" value is available, it will be provided to your code without any comunication to the OPC server or the device. There are parameters to control the maximum age (default is 1 second). So, you can have the browse poll for the data and use ReadXXXX in your Web app server-side code.
Admittably, this does reduce possibly unnecessray traffic between the browser and the Web server, but that can be done by extra coding; but please understand that trying to use SubscribeXXXX will not bring that benefit either.
Best regards,
