============= Meeting 23-Jan-2013 =============

Agenda
======

MORNING

Overflow / Open Issues

Skype/Titanpad vs. Google hangout

pvaSrv multiValue issues

New V3 Gateway implementation

Streaming (chunking) NTTables and other large data

pvAccess Authentication and Authorization



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

Present: TK, AJ, MS, RL, DH
Scribe: 


************
NEW TOPIC: Skype/Titanpad vs. Google hangout
************

RL: Google seems to offer better integration of video, shared docs, shared slides, etc.
Problem: How do we integrate "old" Titanpad meeting notes with "new" notes on Google Drive?

Question: how long are the minutes kept on Titanpad? Should we archive the old minutes (to the V4 website)?

************
AI on AJ: Extract all old titanpad minutes into files (html preferably) on the sourceforge website and update the links.
************

Question: Should we switch to using Google hangouts instead of Skype conference calls, and when?

************
AI on RL by end of week 06: Find out how to create regular hangouts for the telecons
************


************
NEW TOPIC: pvaSrv multivalue issues
************

RL: There is a configuration of a group from a file, and it publishes the result under a name. This is just a plain file without proper syntax or macro expansion.
There should be predefined groups available as well as on-the-fly creation of groups.
RL: return type is an unnamed top level structure of NT_SCALAR and NT_SCALAR_ARRAY structures.
    No Alarm or Display information at the top level.
AJ - it would be nice to support both preconfigured groups and on the fly creation.
RL - we have an RPC service to create groups, and a local API within the IOC.

Operations:
    Create group takes arguments group name, (once_only, specific lifetime or forever), monitor latency period, require atomic.
    Operations on the group by group name (get, put, monitor).
    Delete group by name.

************
RESOLUTION: Rename "multiValue" to "molecule" = bound collection of atoms.
************

ISSUE: How to persist remotely-created groups over a reboot?
    Consider using auto-save/restore for this, not convinced whether this is the right place.
    Would like to use the mechanism for saving files that save/restore has, but use a different file.


************
NEW TOPIC: New V3 Gateway implementation
************
TK: PSI has finished the implementation of a new V3 gateway, which is not based on gdd/CAS, but acts more like a switch or firewall: The raw CA message stream is fanned out to clients. Reason were problems with the CAs based Gateway: e.g. large arrays (images) have to be received completely by the Gateway before it can start sending the update out to its clients.
Implemented in C# on Windows.

Group: Encourage the authors to give a talk about it at the next EPICS Collab meeting in Diamond.


************
NEW TOPIC: Streaming (chunking) NTTables and other large data
************
RL: This problem is on application level - our definition of NTTable requires a pvAccess server to have the complete table in memory before it can start sending it out to the client.
MS: Full implementation - client asks specifying number of rows and offset, gets the matching part.
RL: Light implementation - client asks for the whole table, but gets sent parts, each being an NTTable that is flagged as "more to come", until the last one which is flagged "end".
MS: This requires a change in the pvAccess spec for RPC, which currently defines the RPC as "one request, one answer".
We will also need the ability for a client to cancel an ongoing RPC request.

************
AI on MS : Check which changes are necessary in the pvAccess spec to allow this.
************


************
NEW TOPIC: pvAccess Authentication and Authorization
************

BD: Should not be part of this year's charter.
DH: Then pvaSrv on a V3 IOC is a security hole, and not implementing authN will prevent installations to use pvaSrv.
AJ: Could pvaSrv use CA's Access Security? Probably.

************
RESOLUTION: pvaSrv will use a configurable user name and the pvAccess client host name, and utilize CA Access Security for its local V3 access
************
That will allow to restrict access to records for V4 pvAccess clients similar to controlling access for a PV Gateway.
DH: That should be good enough.

************
RESOLUTION: Pluggable AuthN and AuthZ will not be part of this year's charter
************