Present: BD, MK, MS, GS,TK
Scribe: mostly TK
New topic: Status for Beta 2 release
MS: Modules are ready, tests pass
Demo modules need some work
Should be ready by next week's meeting
New Topic: locksets
Implementation does look like it is optimized.
When a link is modified dynamically only the records in
the lockset to which the record initially belongs
have their lockset recomputed.
Thus if the original lockset has only the record being changed
it is really fast.
It just means adding an element to the record list
for the lockset to which it is being added.
2) multiChannel synchronous get/put:
There is a function dbLockGetLockId(struct dbCommon *precord)
Thus it is easy to determine if all records in a multiChannel
are in the same lock set.
If so it could do a dbScanLock for one record, do gets or puts to all
the records, and finally call dbScanUnlock.
But it must call dbGet and dbPut and dbProccess NOT dbPutField and dbGetField.
It can not use v3Channel like remote dbAccess does.
Remember that if any of the records are asynchronous then
a multiChannel get/put is also not synchronous.
This would have to be done for each get/put request to the multChannel,
because the the locksets might change between get/put requests.
3) Force all the records in a multiChannel to be in the same lockSet:
Not possible without changes to the dbLock.c.
When it recomputes lockSets it looks at the links in records
to determine which records belong in the same lockSet.
Assume multichannel has rec1, rec2, and rec3
and all are in a lockSet consisting of just itself.
multiChannel can succesfuly force rec1 and rec2 to be in the same lockSet.
But when it puts rec2 into the same lockSet as rec3, the
recompute algorithm will put rec1 into lockSet having just rec1.
Resolution: to use multiChannel, the developer has to put all records in the same lockset. This has to be documented.
AI on MK: Contact AJ about the plan for multichannel puts
New topic: Services
Produce services that produce image and matrix NT types
MS: to produce such services, I would need some data that is useful to demonstrate.
AI on BD, MD: produce some useful data and send it to Matej by next week
AI on TK: Check that the next V4 meeting at PSI would be OK on the week of 21st January. Also check with the detector group people that they are available. Confirm by next week's meeting
Beamline requirements discussion
Database access, logbook access etc.
HDF5 data handling and management
looking at images and matrices
MK: pvDatabaseCPP should be implemented before multiChannel puts
BD: that should be a couple of weeks work. We could use that soon
MK: portable server would be a couple of weeks work. Multichannel puts a week or so.