Re: Agenda for Wed March 21st 2012 EPICS V4 telecon

[White, G. <gr...@sl...>]

If FieldName moves to Structure, then my understanding is a top level Structure can't be named. That
impacts services in a way we haven't discussed yet. There may well be ways around this scenario, but
I was happy to let the present situation stand until we really got to the nitty-gritty of Ntypes
and service exchanges, and was then going to bring this up:

Consider a service that is implemented by one record, say called "bpmOrbit". Say, as you'd
expect, the bpmOrbit data Structure conforms to normative type NTMultiChannelArray. The service's job
is to read bpms from all parts of the accelerator, and publish bpmOrbits, where each orbit is averaged 
over say 100 pulses, from each of those sections of the accelerator as they become available. I 
say "as they come available" because, note, different parts of the accelerator may be running at
different effective rates, so they've average 100 pulses at different rates. For instance, a fast 
kicker may be in at the end of the injector, so the injector gets beam at 100Hz, but downstream of 
it, a linac is seeing beam at only say 30Hz. 

So, the service is publishing one record, and that record contains averaged orbits that may come from
the injector, or from the linac. A client is listening to the server, and updating bpm orbit
displays for either the injector or the linac, depending on *which accelerator section it receives
data for*. It would expect to receive injector data once a second, and linac data once every 3 seconds 
or so. But it couldn't be sure which it is getting based on arrival time alone:

bpmOrbit (injector)
bpmOrbit (injector)
bpmOrbit (injector)
bpmOrbit (linac)
bpmOrbit (injector)
bpmOrbit (linac)
bpmOrbit (injector)
bpmOrbit (injector)
bpmOrbit (linac)
bpmOrbit (injector)
bpmOrbit (injector)
bpmOrbit (injector)
bpmOrbit (linac)


So, in this scenario, don't you want the top level structure to be named "injectorOrbit" or 
"linacOrbit", so the client knows what it received? I don't think use of the "descriptor"
field is rigorous enough. You want the variable's value to be "injectorOrbit" or "linacOrbit".

Greg

On 21 Mar 2012, at 12:29, Marty Kraimer wrote:

> On 03/20/2012 11:57 AM, White, Greg wrote:
>> Colleagues,
>> 
>> 
>> Please find below the agenda for our weekly EPICS V4 telecon [1]. Minutes
>> in titanpad [2].
>> 
>> *Note meeting time in your timezone [0]*. US is now in observance of Summer Time; but Europe
>> isn't. We'll go with the Americans again. Next week we'll be back to the usual time for
>> Europeans.
>> 
>> Agenda
>> ======
>> 
>> 0. Preliminaries (5 mins).
>> 
>> 1. Getting past some sticking points (15 mins).
>> 
>>   Like to propose the following short term assumptions so work can proceed. I think we should
>>   consider these as working resolutions until we change our minds. Making these assumptions
>>   allow pvAccess and Normative Types specification publications to proceed:
>> 
>>      a. Re "Move location of fieldName from Field to Structure":
>>         ->  Fieldname will go with Field, not Structure - ie, as it is now.
>>      b. In Normative Types, re identification of optional fields using "Traits":
>>         ->  We stay with simple introspection to determine whether optional fields we given.
>>      c. In Normative Types, re whether pvAccess itself is aware of Ntype id:
>>         ->  No, pvAccess will have no special understanding of a Structure that expresses
>>            a NType from a Structure that expresses any other system of Fields
>>      d. Re Unsigned API.
>>         ->  To reiterate, unsigned will be developed first as Marty's solution [5],
>>         after which David can propose API modifications.
>> 
>>   If possible let's just discuss whether we can accept these working assumptions
>>   rather than trying to formulate alternative decisions.
>> 
>> 
> 
> Greg,
> 
> Matej and I really really want a to be changed to
> 
> a. FieldName will move from Field to Structure.
> 
> Both a and d involve changes to pvData, pvAccess, and to the pvAccess 
> network protocol.
> This will be disruptive so we do not want to cause this kind of 
> disruption twice.
> 
> Marty
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure