Agenda
======
0. Preliminaries, 5 mins

1. Status. Review of core module status w.r.t. Beta 2. *Marty*, *Matej*, 10 mins

2. Normative Types self-id [1]. *Greg*, 10 mins

3. NTURI and Service API [2]. *Greg*, duration - until we can't stand it anymore, and < 50 mins

[1]   http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes.html#normative_type_instance_self_identification
[2] http://epics-pvdata.sourceforge.net/alpha/EPICS_URI.txt


Minutes
======

Present: MK, TK, NM, GS, JR, DH, BD, GW, RL
Scribe: TK

*******
NEW TOPIC: Review of core module status w.r.t. Beta 2
*******

Matej wrote:

Pending:
- demo use-cases
   - update eget to new Service API, new ID strings (now I use "NTTable" strings for IDs)
- update RPC documentation
- rename ServiceClient to RPCClient

Will not go into beta2:
- revise BaseChannel to be moved to pvAccessCPP

MK:

Working on doc for pvIOCCPP (incl. Dirk Requirement)
Still have a problem with arrays for v3Channel put.

GW: priority on demos for the next meeting. 
prioritize work for demos and functionality to be packaged for the next release.

======
New topic: Normative Types self-id
======

Comment from Matej: namespace is long

Matej said

We use "String Field.getID()" as an ID.
pvAccess won't do any parsing/processing/etc on this ID; and won't be
bound to XSD (in future). It's just "a string".

GW: looking for possibilities to shorten that

use URI to do namespacing (like XML)
pvAccess will not force any schema binding

GW: we have a formalism to identify the normative types that seems to work in practice

======
New topic: service API
======

Matej said

Allow server-based authority.

Service API is basically "pass parameters as strings" in an NTURI. If
string parameters are OK, I'm fine with that.
(Note that programers will complain that the need to do parsing.)

Define a standard request that gets you a "service help" back.

Matej

---

Keep in mind:
- Service API is build on-top pvAccess RPC (it just standardizes pvArguments)
- NT types are build on-top pvData/pvAccess (it just standardizes Structure-s)
- pvData/pvAccess won't contain any NT/Service API related code
(all the proposals above are OK with the notes).

GW: What would identify an authority. Write and ask Matej the details more clearly

Has anybody seen any obvious things in the URI proposal? ....silence....

http://epics-pvdata.sourceforge.net/alpha/EPICS_URI_proposal.html

RL: how about escapes in the query strings 
MK: is there a simple way to put the queries in quotes.
Answer: No,  escaping should be used

JR: are we supposed to send array-like arguments to services
GW: Yes
Example: setting a bunch of magnets in one go.
JR: Will pvget tools then support array parameters
GW: you can upload small arrays as parameters, but it will be clumsy

JR: Are you proposing that pvget and so on allow one to use URI syntax?
GW: Yes, I think that would be good, but not necessary. 
    GW: Gives examples of pvget command lines, to show show that one might support "URI syntax" or "regular" syntax, and they are equivalent:

pvget quad34:bdes
==
pvget -u pva://quad34:bdes

pvget -u pva://archiveservice/quad34:bdes;history?starttime=2011-09-16T02.12.55&endtime=2011-09-16T10.01.03
==
pvget archiveservice -path quad34:bdes;history -a starttime 2011-09-16T02.12.55 -a endtime 2011-09-16T10.01.03 

RL: escape the timespecs so that they are standard
GW: Bear in mind that this proposal does not say what should validyly go into a query. It only gives a syntax for queries. 
So, saying "escape the timespecs [so that one doesn't have to use .]" is a comment about the example, it's not a
comment about the proposal.
RL: syntax to specify a service:   <service>?<arguments>
RL: I do not like the use of fragments. Explicitly using a part that is intended for client only is not spec-compliant