============= Meeting 09-May-2012 =============

Agenda
======

1. What to do about non-threading channelRPC. (*Ralph* re problem, *Marty* re proposed reaction) 
2. Time domain based dataset Normative Type proposal (*Michael*)
3. Introspection and unsigned C++ version upgrade status
4. New releases for Java and C++ version upgrades. Nailing it down. When and who does it.
5. Schedule and assignment to connect the PVManager interface to Normative types
6. Date of next meeting
7. Will monitoring options be supported under C++?


------------------------ Minutes ----------------------------

Present: BD, NM, MS, TK, MK, GS, JR, AM
Scribe: AM, RL


************
NEW TOPIC: What to do about non-threading channelRPC
************
What to do about threading channelRPC (currently it is non-threading). (*Ralph* re problem, *Marty* re proposed reaction) 
Multiple clients must use the same service at the same time. So multiple clients need to access this at the same time. The directory server gets this at the same time. The  RPC service must be able to spawn off threads that are running in parellel. The service developer will determine the behavoir.

************
AI on Matej (Java) and Marty (C++) will take care of this after the current refactoring. A spearate thread will be spawned for each request. Expected delivery - 2 months. Implement Java first.
************

BD: What first? Java or C++? Probably both shortly after another.

RL: Other similar services (e.g. web containers, db connections) are working with thread pools for maximum performance and safety.


************
NEW TOPIC: Time domain based dataset Normative Type proposal (*Michael*)
************
Greg has taken a stab at capturing what Michael had said. There is still not agreement on this.

************
AI on Bob by [soon]: Ask  Michael to generate the Normative Type proposal for time and frequency domain arrays.
************


************
NEW TOPIC: Introspection and unsigned C++ version upgrade status
************
GS: Fears that it affects servers that are already deployed
MK: Should only be minor changes
Marty: Java stuff is essentially done. C++ version has C++ shared pointers as an issue. Matej can start on the PVAccess section of this. Expected completion in 3 weeks.


************
NEW TOPIC: New releases for Java and C++ version upgrades. Nailing it down. When and who does it.
************
Group is unsure what this is supposed to mean.
[GW: meant when do we intend to release the Java and C++ implementations of the unsigned and
introspection interfave changes, as point releases, ie BETA-2.0.0].  
TK: Should ship a new release after the current refactoring.
Greg was always managing the release process, with James doing a lot of the under-the-hood work.

************
AI on Greg by 3 weeks plus 1 day: Manage next beta release.
************


************
NEW TOPIC: Schedule and assignment to connect the PVManager interface to Normative types
************
BD: Who is going to connect the V4 types to CSS?
MS: As I understand Gabriele, he needs to finish one more layer on top of pvManager

************
AI on Bob by after refactoring and multithreading: Check with Gabriele, when pvManager will be ready for our plugs.
************


************
NEW TOPIC: Date of next meeting
************
TK: Doodle says 11.07.-13.07. looks like the better option with more participants.
RL: Will check if he can make on the 13th.
JR: Is the new date definite?
BD: Yes.

************
RESOLUTION: July meeting date:   11.07.-13.07.
************
BD: expects up to 2⁴ participants.


************
NEW TOPIC: Will monitoring options be supported under C++?
************
GB: Will C++ be limted to RPC
MK: That would need the pvIOC on C++.
GS: Some of the planned services will need monitor functionality.
MK: That could be done by directly overriding the monitoring methods. The database would take care of the threading issues in a general way.
Implementing this in C++ would be a 0.5 man year task.
Suggests trying to implement monitors and see how complicated it gets.
The Java version has most of the framework. If you run your service in a record, the basics are there.
GS: doesn't want SWTshell nor XML in the IOC.
MK: May do XML stuff last.
GS: XML record definition is an unsightly mess, hard to do.
MK: XML allows to define record without writing code.
RL: pvIOC functionality has not been reviewed yet. Should do this before writing the second implementation.
MK: The V4 IOC engine design should get higher priority.
MK: SWTshell is an important debugging tool - someone should reimplement something like this for the c++ version.
Upcoming meeting should have a session on this.
BD: After the beamline discussions, we should generate a basic statement of what a V4 IOC would be.

************
RESOLUTION: At the upcoming meeting, have 0.5 days about beamline requirements and 0.5 days about what a V4 IOC should be.
************

End of meeting 14:49 UTC