Menu
▾
▴
RE: normative types
|
From: Shen, G. <sh...@bn...> - 2011-11-18 12:18:05
|
Hi Timo, Exactly as you said, the reason to have those 2 is "if it is valid (alarm status) and when was the data acquired." This is for reading operation. However for writing (put operation for example), how to compose those 2 fields? It does not make sense to set those 2 fields. Also it is in wrong side to set those 2 fields which should be determined by a server. For example, I want to send a double value to server. It is very nature to use NTDouble to carry the data. However, because of the alarm and timestamp, I can not use the NTDouble for this operation since there is no way or no meaning to determine the alarm the timestamp. Then what will happen? We have to define a set of NT type for reading (get operation), and another set of NT type for writing (put operation). Moreover, since we have getPut operation in V4, which data type should we use? We are still in trouble to determine a correct data type. Since the different between 2 sets might be the alarm and timestamp only, the best way to solve above problem is to make those 2 fields optional. Guobao -----Original Message----- From: Korhonen Timo [mailto:Tim...@ps...] Sent: Fri 11/18/2011 2:47 AM To: Benjamin Franksen; epi...@li... Subject: Re: normative types We had a quite extensive discussion on this at the EPICS workshop. If I remember correctly the resolution was that timestamp and alarm should always be sent, everything else is optional. The reasoning for this was that for each value you want to know if it is valid (alarm status) and when was the data acquired. I found that this is a valid reasoning (one could argue about the idea of encoding data validity and alarm status together, but I think it is a reasonable compromise.) Since the idea of the normative types (please correct me if I am wrong) is to enable writing generic applications to handle these types, I would vote for sticking with what Marty described here. If somebody wants to have an application that _for sure_ never needs time stamps and/or alarm status, it is still possible. But not using normative types. Just my 2 cents. Timo Benjamin Franksen wrote: > Am Donnerstag, 17. November 2011, um 15:45:17 schrieb Shen, Guobao: > >> On 11/17/11 5:17 AM, Marty Kraimer wrote: >> >>> [...] No an NTScalar is: >>> >>> structure NTScalar >>> >>> timeStamp_t timeStamp >>> alarm_t alarm >>> scalar_t value >>> // following two fields are optional >>> display_t display >>> control_t control >>> >> Then I would like to say >> >> structure NTScalar >> scalar_t value >> // following two fields are optional >> >> timeStamp_t timeStamp >> alarm_t alarm >> display_t display >> control_t control >> > > Very interesting diskussion. Seems we are now at the point where CA was a few > decades ago... so what do we demand is present? And what is optional? If we > demand all of the standard meta data to be present we are mirroring a CA CTRL_ > request type. This is surely not the idea... > > So I'd like to agree with Guobao: since the client can always ask what the > server supports, let the other fields all be optional. OTOH, if we do that why > use an extra type at all? I mean: in PvData/PvAccess any structure can have > any number of (additional) fields, right? So what makes NTScalar special if > compared to just a PVStructure with a scalar field named "value"? Why even > mention the other fields? Or is the idea that *if* an NTScalar has a (direct) > subfield named "alarm", then this subfield must have type alarm_t? Seems like > this would be the essence of what NTScalar is about. > > When I think about optional fields of a structure, I can't help but notice > that optionality is just one very special case of a tagged union. It seems > these are more often used/required than has been acknowledged before. > > Cheers > Ben > > ________________________________ > > Helmholtz-Zentrum Berlin für Materialien und Energie GmbH > > Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V. > > Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph > Geschäftsführer: Prof. Dr. Anke Rita Kaysser-Pyzalla, Dr. Ulrich Breuer > > Sitz Berlin, AG Charlottenburg, 89 HRB 5583 > > Postadresse: > Hahn-Meitner-Platz 1 > D-14109 Berlin > > http://www.helmholtz-berlin.de > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d -- Timo Korhonen PSI (Paul Scherrer Institut, http://www.psi.ch) CH-5232 Villigen PSI tel + 41- 56 3103262 fax + 41 - 56 310 5090 e-mail: tim...@ps... ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d |