Agenda for 2013-11-05 Telecon


1. Report on Heesterman Windows port (MS)

2. Simplified Branching Scheme (RL)
http://epics-pvdata.sourceforge.net/hgflow/using_hgflow.html

3. The future of pvRequest (AJ)

4. Any Other Business
* Agenda for next meeting

Minutes

Attendees: DH, GC, GW, MK, MS, NM, RL, SV, TK, AJ

Scribe: SV

Chair: AJ

1. Report on Heesterman Windows port (MS)

MS: took sources, compared to 4.3 release; there aren’t many changes. He added MS VS to modules; biggest changes related to windows export/import; other changes are typically minor; should not be problem with merging changes; some changes are in the epics base, those might cause some problems

AJ: I saw those changes, going through them; have not finished all; some made sense and are already published (e.g., alarmString.h); some changes already have their equivalent in 3.15; the only issue is going to be with sharedLib (he changed meaning), which would affect lots of non-base code, and this will not be accepted

AJ: These decorations can be used on linux, with some changes in configuration.

[GW: Q: can we merge PH’s stuff into 3.14, in case we proceed with 3.14 & 15?]

AJ: MS should try and import PH decorations and see if stuff builds

MS: I do not have windows machine for build; but I can get VM; I should be able to do this quickly

GW: Is AI appropriate for integration that is not dependent on changes on base, or just those for adding decorations?

AJ: ANS: should be just decorations

GW: What the heck are “decorations”? [GW: I didn’t put it this way!][SV: tough, I’m the scribe] GW: :-)

AJ: Things in italics below:

    epicsShareFunc void epicsExit(int status);

    class epicsShareClass epicsMutex {

GW: Matej, can you clarify whether you assent to section 2?

AJ: ANS: Sec 2 is my responsibility, MS starts with Sec 3.

AJ: Some stuff in Sec 2 will be accepted, some will not. Sec 3 is relevant for this group.

DH: To what extent those changes depend on base? Would like to be able to build V4, especially pvData, pvAccess, pvCommon against existing base, especially 3.14.12.3.

AJ: explains the changes in more detail; look in shareLib.h; there are lots of comments there

MS: I am not 100% sure now whether current implementation is functional

AJ: it is, I build it on windows all the time.

GW: after PH changes, if they are accepted, are we going to allow VS build?

AJ: Not keen on it; there are issues with importing project files, etc.

MS: what do you need to build epics base without VS>

AJ: you can use cygwin; you can use mingw with particular version of make; you can also use MS compiler

MS: if we go to windows, use MS compiler

AJ: sure, we can; you can distinguish between compilers by using different target arch name

AJ: there are instructions on epics website on how to build with windows

MS: ok, I’ll do it, after union stuff

**********

AI: MS to synchronize use of decorations in V4 code.

AI: AJ will accept/reject changes in Section 2; those that are necessary for 3.14, but in general they will be accepted for 3.15. Those that are needed for v4, then they will go into 3.14.12.4

*********

GW: What is implications for using this in 3.14/3.15???

AJ: Should be no need to merge into 3.14

AJ: I have not tried building v4 on windows; so I am not sure if some changes are necessary

AJ: I do not want to make unneeded changes

GW: What about VS stuff? RL thinks IDE configuration does not belong to repository

MS: If we support VS, we need to have it in??

AJ: VS requires set of files for each executables

RL: on windows I unpack stuff and type make

GW: agrees with RL, it is not hard

GW: we also have eclipse stuff in our projects; those are IDE specific; if VS did not demand reorg of repository, we would have allowed it, but it unfortunately does that

MS: when someone ads new file, makefiles need to be changed; the same is with VS

MS: we’ll try with make

GW: we (epics4) will support development with makefiles on windows; if Peter wants to use our mercurial for repository; is he free to do that?

AJ: I am not sure if there are parts of his installation built into those files

RL: against having this in the main repo

***********

RESOLUTION: We will support MS compiler in our repos but using make only; if PH wants to he can host contributor directory for VS build files in our mercurial repo.

***********

AJ: He probably will not want to maintain this.

2. Simplified Branching Scheme (RL)
http://epics-pvdata.sourceforge.net/hgflow/using_hgflow.html

SV: Good doc!

RL: Left for 20 minutes to inject beam...


3. The future of pvRequest (AJ)

AJ: Had number of questions

To Summarize:
 * pvRequest is a PVStructure.
 * Client passes a pvRequest to the Channel's create methods:
     createChannelProcess, createChannelGet, createChannelPut, etc.
 * No query or introspection is possible; the pvRequest object must
   be generated client-side before calling createChannelXxx()
 * pvAccess gives a convenience parser for generating pvRequests.
 * The parsed language uses a syntax MRK invented for the pvIOC.
 * The parser is strict, e.g. can't insert spaces before ([{.

Questions:
 * Is the generated pvRequest structure just an object of the value
   type expected from the server, or somehow related to that?
 * If yes, does it have to be?
 * Does this make sense for servers not based on pvIOC data model?
 * Is this parser/language still optional?
 * Do the command-line pv/ez tools work with other servers?
 * How hard would it be to replace the parser with something else?
 * What other languages might work here? JSON? XML? ...?

MK: top level pvaccess does not know anything about pv structures…

AJ: the client needs to know what pvrequest contains

MK: server has to know what structure is expected

GW: is there common syntax and semantics?

MK: there is recommended syntax and semantics

GW: there is recommendation for fields that need to be there.

MK: Right

AJ: does client have to create structures…?

AJ: sounds like each server needs to document its own pvRequest.

NM: AJ is correct;

MS: channel get gets request which fields to get; we need to standardize pvRequests for different pv providers; but we should retain ability to have optional fields

AJ: example is for monitor; if I setup monitor, I want to tell server things like “this is how often you want data, etc.”; this stuff should go to pvRequest object, but there is no standard on how to do that

MS: we need to standardize what goes into pvRequest and what parsers should look like

GW: we agree, we are just discussing some optional parts; it sounds like pvRequest is the same as XMLHTTPRequest object (http://www.w3.org/TR/XMLHttpRequest/); we should be at least informed about the work that was done for XML HTTP; we should not try to build it from scratch

MS: one should be able to see pvRequest in human readable form; also, should be able to encode pvRequest in URI;

MS: also should not limit users from putting proprietary things.

GW: Yes! Precisely!

NM: concerned about RPC; is it too flexible? not sure if syntax in v4 addresses all requirements for RPC servers

GW: say you want to set large number of magnets to a value; should be done with put/get, or with RPC using pvRequest with structure

MK: should leave possibility for client to ask server for structure that server offers.

SV: confused as usual

GW: you could make request for request object

GW: we tend to know what we are doing, so at runtime we rarely need to know server functionality

GC: have use case; if there was automated way for service to describe its functionality, in CSS studio we could automatically create BOY screens for this

AJ: could we introduce introspection mechanisms? e.g., passing empty pvRequest object…?

NM: good idea

GW: let’s not let this out of hand… these are esoteric? cases that are holding up progress…

AJ: but collecting requirements for pvRequest enhancements is not a bad idea

GW: agreed

NM: these are two different topics: structure of pvRequest and syntax

MK: it should stay as pvStructure, as we know how to handle this

GW: what are the alternatives?

AJ: if we use pvStructure, it is easy to implement/standardize this in a generic way

NM: what about existing syntax?

AJ: do not worry about existing parser (not keen personally)

NM: these are 2 different parts to this topic, request syntax and structure.

AJ: agrees

MK: complete doc is in pvAccessJava.html (for createRequest)

http://epics-pvdata.sourceforge.net/docbuild/pvAccessJava/4.3.0/documentation/pvAccessJava.html

AJ: who will work on this?

AJ: start by collecting user stories, examples, requirements, etc.

NM: I can send some user stories

MK: Matej can say what pvManager requires

GC: I can send my story about CSS

MK: volunteer GC to get work done

GW: will send some user stories as well

************

AI: AJ will start collecting all user stories; everyone should send those to AJ

*************

2. Simplified Branching Scheme (RL)
http://epics-pvdata.sourceforge.net/hgflow/using_hgflow.html

RL: … returned

GW: can I comment before RL?

RL: I replied to your email, no problem with your statements, you were right about everything

GW: needs to leave, control room issues

RL: Full blown Driessen model is too large for us, we came up with shorter version; one dev trunk with feature branches; when dev trunk is good for release, we branch to release branch and do tagging on this release branch; this then does not block dev branch; release branch is kept open for all bugfixes

RL: hgflow plugin adds high level commands; the doc shows plain hg commands with hgflow commands; there is one or two cases where hgflow helps

RL: I like hgflow for autoshelve functionality; allows you to keep changes on your branch; you do not need to commit everything

AJ: All tagging currently happens on the release branch; we need one tag on the dev branch as well to show where the release branch started from.

RL: yes; we can add tags as we find appropriate

AJ: if I make changes on the release branch, we need to merge back to dev branch

RL: doc should explain this

AJ: it does

AJ: I am happy with this model

RL: CSS guys use complete model; fun to explore

GC: was distracted, cooking lunch, no comments

MK: AJ, are you updating release doc?

AJ: yes, release doc needs to be worked on

RL: no need to do anything with repository structure

RL: need to create release branch for 4.3.0

********

AI: AJ will update the release doc to reflect this model

AI: RL will start the discussion on labeling branches

********

AJ: do not like numbers for ABI/API? GW’s point was:

5. I assume the number of fields in the release tag is not assumed to be
or limited to 3 max by hg flow?. Hg flow doesn't try to manage the numbers
for you automatically does it? I'm coming to the conclusion we need 4 to disambiguate
protocol changes from ABI changes. So it will be protocol.abi.api.other.
Presumably that's not a problem for hg flow.

RL: should we refrain from creating branch until we agree on this

RL: agrees on AI

AJ: complains about his own AIs

4. Any Other Business

None.