- being able to "T off" an existing data stream heading to a PI Server so there are no network roundtrips if you have an application close to the source of the data.
- not sending data to a PI Server, but sending data to a "dynamic tag" that a client registers with an instance of PIBufss. More like a method of data exchange from an OSIsoft interface directly to a client application/system built with AF SDK/MDA. Possibly even allowing customers to implement custom logic between PIBufss and a PI Server.
Anyway, I am really just fishing to see where that particular feature is heading.
After all PIBufss is more or less a mini, watered down PI Server.
With your suggestion it is getting closer to a full PI Server! I will let the PI Server team opine officially on this but I am curious how the benefits of adding such complexity warrants it. Is the round trip to the PI Server a bottleneck in your application (first scenario)? What would be the benefits of working around the PI Server in the second scenario?
I am sure you got some cool reasons for asking this; why does the proposed architecture kind of reminds me of a fractal?
A primary motivation for being able to get updates from a PIBufss session would be latency, but also relevance. For latency the issues are historic, some networks within an organisation experience varying reliability, bandwidth and latency, which usually forces placements of applications/systems within that architecture. I see PIBufss in those scenarios as a lightweight protocol when compared with the heavyweight PI Server, just think about administration of the two. PIBufss takes care of itself, the PI Server needs maintenance.
Also, thinking ahead for when we have multi-collective PIbufss. Then one would have even more reason to have access to a PIbufss session - you get to data as it is buffered for multiple locations from one spot, no need for multiple connections.
For the "dynamic tags" angle to PIBufss I was day dreaming about something particular at the time (it escapes me right now) but one use case would be ad hoc data analysis triggered by some kind of event. During the ad hoc analysis you may have an application that already has a T junction to the PIBufss data stream to a PI Collective, but all the data needed for troubleshooting analysis is not currently within that stream. So...the application registers itself directly with PIBufss (well maybe it talks to the Interface via UniInt somehow as well) that it needs data for a bunch of data points, thus creating the dynamic points with PIbufss. Once the period of analysis is completed the application deregisters the dynamic points. Job done and not a PI Server administrator is sight.
Maybe I was thinking about custom compression algorithms in a multi-collective PIBufss world... PI Interface => PIBufss => Dynamic Tags => Custom Compression Application => PIBufss => PI Server/Collective tags.
Interesting. Some of the use cases you mention may be addressed by the new Data Pipeline, although perhaps not exactly how you described. Will you be at the Hackathon to try this out?
Timing of Hackathon sucked for me so not there.