Allow tag for acsys.sync event requests

[rneswold]

@kjhazelwood : Like is allowed for dpm entries, allow a unique integer tag for each event request.

[rneswold]

The sync service is more lightweight than the DPM one so I was thinking you could make different streams for each event (if you wanted to tell them apart.) I guess it depends how related the event processing is from your DPM data processing. If there's no correlation, they could be done in separate, async functions.

I guess what I'm trying to say is, rather than trying to do everything in a single loop, do the DPM stuff in one loop and each event processing can be done in its own loop (via concurrent, async functions.)

[rneswold]

@kjhazelwood : can you describe your use-case? Do you need clock events interleaved in the returned data. Do you need multiple clock events reported in the data loop?

[kjhazelwood]

I often use tag or ids to specify which index to put data into arrays. I think the more similar to dpm the better as I often monitor both events and readings in the same script and it would be nice to not have to have two different mechanisms. That brings up another question: Must the tag (for dpm currently) be unique? I can see instances where I might want clock/reading requests to share a tag such as the when I want to replace the value in an array with the latest clock event not necessarily put a certain clock event somewhere in the array.

[charlieking65]

Currently the tags in DPM need to be unique. If you add a duplicate tag to the list it will replace the one that's there. You could define banks of tags to correlate the overlapping replies.

[rneswold]

If we add tags to SYNC, they'll only be unique to SYNC. The DPM tags are unique to DPM. The Data Pool Manager uses the tags so you can easily remove a DRF request or replace it just by specifying the tag. It doesn't have any further purpose than that.

[kjhazelwood]

Sure, I didnt know DPM was using the tag argument underneath the hood. Perhaps it's not a good idea to expose this to the user if they can overwrite their requests by speciying the same tag (the name tag doesnt sound unique, perhaps rename to something that sounds unique like id?) I guess my purpose for the tag is really more of a handler name. If we supported callback/handler methods then I guess my use of tags would be a lot less.

[rneswold]

DPM is only using the tag as a key to the DRF request. It can be any value you want. If you associate a new DRF value with the tag, it replaces the old one.

The Web parameter page, for instance uses the tag to specify the row on the screen.

(I think the protocol compiler specification calls the field, "ref_id".)

[beauremus]

I'd like to understand your use of DPM and SYNC in conjunction a bit better, not specifically about the tags. I'll ask a kindergarten question in hopes of a kindergarten answer 😁
Why do you need associate DPM and SYNC responses, aren't event-based requests a solution to your problem?

[charlieking65]

The use of 'tag' is just a python misnomer. The value is referred to as a 'reference id' in DPM and other DPM clients.

[rneswold]

@kjhazelwood : In issue #6, I give an example of processing sync events and DPM data in different functions. Can your use-case benefit from that approach?

[kjhazelwood]

@rneswold I think #6 is a nice way for separating sync and dpm processing, thanks. However, the purpose of this issue was to allow a user defined "tag" for handling of the response from either sync or dpm. 99% of my intent for doing this is to dump the event or reading to an array at an index I define with the "tag". I find this is the most efficient way to dump readings as fast as possible with the least overhead and code. Sure, I could create a dict with drf/event request keys to have a lookup table but that just seemed like unnecessary code since dpm seemed to already be allowing a tag. I now know the tag is not what I thought it is so I guess neither dpm or sync actually have the feature I requested. I think its safe to close this out.