* Status updates (everyone)

 * Requirement for a short document on configuring pvAccess

   in a real world V4 installation.

 * new NTMultiChannel normative type [2] review .




    See Marty's inclusion in that email  





Topic: Status Updates


AJ: Working on 3.15, Working on Codeathon, Sinisa will attend and work on pvaPy.


GS: MASAR, integrating with MongoDB for backing database, developing migration tools, close to finished.

GW: Did Nikolay show that at the F2F? Is MongoDB fast enough

GS: So far yes.

GW: When I looked a while back NOSQL Databases were slow, curious what performance is like now.

GS: No perf tests yet, need to be careful to tune, can be better than MySQL in some cases. Must be careful designing schema. Don’t know much about Nikolay’s work.


DH: AD in pvData/NTNDarray, more stable. DH may have found the cause of the seg faulting bug.

MK: MK also didn’t understand why the fix of DH worked to fix the segfault! Issue may be monitoring in pvDatabase

DH: problem might be in pvDatabase(?),

DH: merge between image /NTNDarray


MK: working on pvIOCJava, get XML code fast, 1.5 week work already, and close to the end


MS: remove setlength() from server/client, fixed array was done in Java, not in C++.

MS: Multicast before security(?), prefer pvAccess security first

AJ: Multicast,

MS: Multicast to 2 clients can be solved by adding an additional netowrk card; multicast is useful but lower priority

MS: still have plan to finish multicast before release


RL: codac core system, bug fixing in 3.15, get 3.15 into state for codac core system

RL: pulse configuration system, expecting to get request in 3.15.0,

GW: RL would be a primary driver to release 4.4. Anything not 4.4 would like to see?

RL: configuration guys how would like to see V4 in Codac Core 5, so they can look at it.

GW: adding errors into NT types, how would do use cases, redesign NDMultiChannel, add couple

GW: next week for publication

New topic: Requirement for a short document on configuring pvAccess in a real world V4 installation.

GW: broadcast definition. @SLAC, publishing V4 for others to use

GW: define the relationship between CAJ & V4, nice to have before Thu/Fri?

GW: need abstract definition in at least Java

MS: Client does not need to set anything

GW: SLAC doesn’t use standard port numbers, for example.

MK: Array for performance, does not understand fix array  

AI: on MS, by Aug 9 2014: write a pvAccess configuration setup document.

New topic: NTMultiChannel.

GW: redefined NTMultiChannel quite a lot

MK: Where is doc?

GW: in NT type doc itself now

MK: Need latest version

GW: not switch link to point to this one yet

MK: why not union array, each value is for each channel

DH: it would be better for different value type

MK: a combination of any type V3 channel

MK: whether one NT type to satisfy like MASAR/Channel Archiver, and like BPM/Orbit is a problem


GS: Performance problems with early versions of MASAR due to data structure, this might be similar.

MK: Should use union[], ideal for purpose.

GW: agree structure [] should be union[]

GW: Alarms etc. would be embedded in the contained types. Outer object has the usual NT attributes, but individual data items also have their own. This is a recursive structure of any NT.

GS: You’re proposing each channel is one entity contained by the outer structure?

GW: Yes, and they can be grouped as well. Can reuse the same introspection interfaces for things that are the same.

GS: Then you have to do the iteration to get the values out. Don’t see a quick way to get at the data values.

GW: We need an example/use case, which I used to develop this. Orbit of accelerator.

GS: Yes.

GW: Will send out my example from my notes. Could MK code up an example for this & tell me whether this is efficient.

MK: NT have inconsistency between spec/code/Java/C++.

DH: Don’t change the document to match the code. Camel-case is the main issue, plus abbreviations.

MK: Any code using the NT spec won’t work with existing code, because the names were wrong. MK will send email about this.

Meeting ends, 9:00 am.