Status reports and demonstrations of work for planned version 4.4 features.
1. dbGroup Ralph Lange
RL: No description, no demo, and not intended for next version.
RL: Writing to a dbGroup should be as atomic as possible, maybe requiring a new API to EPICS database.
RL: BF: group writes should not be seen as single (separate) writes, otherwise they should not be called atomic.
KK: What about processing the records?
RL: That’s another issue (ordering, PP fields, etc.). This is maybe another thing for pvRequest.
BD: Who will work on this?
RL: It’s on my list.
AJ: Ignore PP and carry process data (process or not, ordering) via pvRequest. This includes a list of record to be processed (after all writes are done).
RL: Should order be specified too?
RL: Writing to PROC fields allows you to do write, process, write, process. We need to disable to all the processing while doing writes unless if explicitly specified (i.e. write to PROC field).
AJ: That shoulds right.
BL: It would be a good thing to have a put that does process and the only does not process.
RL: We already have this (specified via pvRequest):
MK: Yes, but the default is to process after put.
AJ: We might need a change in dbAccess (additional put method). But this should not be a problem.
KK: Is it OK not to process on every put? It calls for unexpected state. Why not leaving the current behavior and the client must make sure to process to happen?
AJ: No, this is not OK. We do not want to process after each put (then group writes are no longer atomic).
RL: Right. There are 2 uses cases (process on PROC only proposal and KK proposal). Maybe we want to have both.
MK: Another issue is when to post monitors.
RL: I do not like PROC only proposal… it assumes there is a PROC field (bound to V3). We need a separate ordered list of record to process.
RL: Do we specify it on dbGroup to create or per request? (i.e. the list is part of group specification).
SG: Can we have a group of group(s)?
RL: If we use MultiChannel this is possible. I would think this just works.
RL: MultiChannel is by definition unlocked version, so locking should not be an issue.
BD: Let’s say no for now and maybe it will just fall-out.
RL: I do not see locking across over IOC really happening.
AJ: I agree.
RL: We do not have a NT-type for group of channels.
BD: Make one, implement it.
RL: NTMultiChannel has only data of channels, the new NT-type should contain more data.
MK: I will propose an updated version of NTMultiChannel.
AJ: It’s too early to specify a NT-type now. Invent a type (do not call it a NT-type yet), implement the code and at the end we might make it an NT-type.
RL: I have another 2 separate smaller issues.
RL: CAJ connecting to many (>10,000) channels does not work reliably, comes into weird state of cponnecting many, but never all channels. (Client: BEAUTY archiver.)
BD: Can we get a contract to get CSL to fix this?
MS: Me and Murali worked on this and after some fixed he was happy with the solution.
RL: Will point Nadine in that direction, CCing Matej, Murali, and Gabriele.
MS: What about specifying server address when connecting to a channel? Or using nameserver? Should we add this method to CA API.
RL: Another issue.
RL: In Ljubljana we agree that data need a second timestamp to monitors (when the update was caused). Needed for archiver.
BD: Does this change the protocol?
KK, MK: What about to change structure’s timestamp?
RL: The cleanest way is to send timestamp on every update that it sends out (optional).
MS: What about a feature of attaching a metadata to each monitor update?
BD: What about using clients timestamp?
RL, MD: No.
BD: No time, no money, solve it on the client side.
--- break ---
Version 4.4 Feature List review
Marty reads list of features from featureList (http://epics-pvdata.sourceforge.net/internal/proposedChanges/featureListR4.4.html)
MK: List of topics for discussion from feature list.
MK PortDriver should not be part of 4.4
MK: Status of pvRequest. Need to be able to ask for subset of fields.
AJ: pvRequest doesn’t allow pvaSrv to do all server-side filtering we require. Ralph has other questions.
RL: Currently only server side monitoring has deadband. Client could have deadband. Channel provider provide default. How does client say use default..
MK: Currently request has record with key value pair options. Options on individual field.
RL: Very hard to write clients because no standard for pvRequest (NTPVRequest).
MK: There is clear semantics for subfields. No standards for options.
AJ: Would like to see BNF definition
MS: Must be a string to put in NTURI.
KK: Don’t like having to type -r “field(...)”
MK: Just do -r “name”
DH: Works (e.g. pvget -r "codec,attribute" adImage)
MK: _ signifies fieldname not real
NM: Consider pvRequest for RPC. Could standard for services.
MD: Similar problem to HTTP. Headers can be almost freeform. It’s a mess we should try and avoid.
MK: Now fields are well defined. Options remain. pvaSrv drive requirements for this.
AJ: Ralph has carte blanche.
AJ: Create is first place pvRequest send pvRequest before introspection.
AI: On RL for next release (4.5?) to come up with standard for pvRequest.
Discussion on MS proposal for fixed and bounded array.
MS: Requires protocol change. API change. Have in local copy but needs agreement to add.
NM: Asks about relation with MDs’s array changes.
MK: If going to do this have to do it now.
Argument over whether API should change to actively discourage people from creating unbounded arrays.
MS wants to get rid of current create array API that creates unbounded array to actively encourage all users to only use bounded arrays, Bob agrees.
DH: Keep existing API and add bounded as overload. Don’t make users prematurely optimise when don’t have to. Don’t break existing APIs.
MK: What is performance benefit.
MS: Able to preallocate buffers.
KK: Is needed for AD performance.
BD: mem allocation expensive.
Add fixed and bounded arrays and bounded strings without breaking existing API
addFixedArray(name, type, size)
MK: Stride added to C++ array ops but not Java because conversion API needs to change.
Discussion of whether setting capacity remotely is needed.
MDs: Don’t need it
AJ: Do implement what don’t need.
MD: Capacity should never be sent over network.
MD; Allowed to write beyond bound (length)? Bad. Prefer set length and write.
Don’t like fuzziness here.
MK: ChannelArray V4 version of array record. It’s been there 7 years
MD. Not a compelling argument.
Resolution: .Remote (on wire) channel array capacity ops go away.
Argument over whether writing beyond length is useful useful.
What about a append.
MD says no (if want append create new append PV)
BD: Says yes.
BD: No use case for append.
Arrival of lunch facilitates agreement
Resolution: Channel array. Writing beyond current length prohibited, i.e. offset + dataLength * stride <= length
NM: Asks whether sharedData() will be 4.4.
MK: No removed.
MD: New API better.
MK reviews API changes to pvAccess.
MK: GW wants to add error to NTs. Won’t discuss w/o GW present. Generally a feeling that this needs discussion.