From: Benjamin F. <ben...@he...> - 2012-02-25 20:22:07
|
Hi Nikolay good to hear from you again. On Samstag, 25. Februar 2012, Malitsky, Nikolay D wrote: > To me, the type definition must be explicit. It is prerequisite for > maintaining the type IDs. Does that include presence/absence of optional fields? For instance, do you regard NTBooleanArray1 boolean[] value and NTBooleanArray2 boolean[] value timestamp_t timestamp as the same type (with an optional timestamp field, leaving open how to specify the optionality) or as different types? Note that CA /does/ view them as different, and gives them different IDs. But it allows only a small number of combinations. > At this time, I am working on the type registry in the context of the epics > archiver. According to this approach, type can be identified by name ID > (using namespace and version) and integer ID generated with MD5 hash. > As a result, the present parametrized types will be instantiated into the > corresponding explicit variants. But personally, I consider that types > must be explicitly defined from beginning. My gut feeling is that this would be wrong. I think abstraction almost always wins out over mindless repetition. Even if IDs are not assigned to the normative types in a systematic way, but rather by counting as they come along, all that needs to be spelled out explicitly is the (big) table that associates each single type with its ID. For example, the table could look as Id Type -- ---- 1 NTArray<boolean> 2 NTArray<byte> ... but we could still specify (once and for all) NTArray<scalar s> s[] value Cheers Ben > -Nikolay > > ________________________________________ > From: Benjamin Franksen [ben...@he...] > Sent: Friday, February 24, 2012 7:11 PM > To: epi...@li... > Subject: Re: Normative types scalar_t is non-terminal right? > > Marty > > if you would consider to give your thoughts on the questions and > considerations below? I guess you would be the one who has the best idea > currently. > > Am Samstag, 25. Februar 2012, 00:28:08 schrieb Benjamin Franksen: > > Am Freitag, 24. Februar 2012, 20:23:32 schrieb Marty Kraimer: > > > "PVData Meta Language" . > > > > It seems that in order to describe the 'normative types' in a way that is > > clear and unambiguous, it would need some extensions, though. But I could > > be wrong: maybe the problem lies deeper and in order to support the > > normative types pvData itself must be extended in non-trivial ways > > (support for either unions or type subsumption). > > I remember that during the last EPICS meeting, there was some controversial > debate about globally fixed numbers (IDs) for the normative types. > > Can someone summarize the current status? > > I ask because having a fixed ID also fixes the question of type identity > (for the normative types, at least). If different types must have > different IDs, then something like NTArray that (with what pvData supports > today) is not a type, cannot have a fixed ID. Instead there must be > > NTBooleanArray, NTByteArray, ..., NTStringArray > > each with a different type ID. This would settle Greg's question: writing > > structure NTArray > scalar_t[] value > > is just a scheme, it is not an actual type description. However, imagine > some more advanced type scheme that contains more than one field of type > scalar_t, like this (maybe a bit artificial) example: > > structure Converter > scalar_t input > scalar_t output > > Here it is not a priori clear whether this a scheme with one parameter (so > that both input and output are supposed to be of the same scalar type) or > whether it is a scheme with two parameters (so that input and output may > have different type). The current notation cannot make the distinction > clear because it fails to designate the field type(s) as parameters to be > passed to the type scheme. > > Apart from that, there is the issue of optional fields. Is > > NTBooleanArray1 > boolean[] value > > actually the same type as > > NTBooleanArray2 > boolean[] value > timestamp_t timestamp > > ? The introspection interface must say whether the timestamp field is > present or not, right? But if both get assigned the same type ID, then how > can e.g. a client implementation know which of those interfaces to return? > > So, I think either pvData directly supports optionality of fields (support > for unions would subsume this, of course), or else we need different types > for all the variations (with or without timestamp, with or without status, > severity, etc. pp.) leading to a huge number of types. > > I am certain these questions must have come up when trying to implement the > normative types as I gather already happened. Maybe the conclusions just > need to be written down and all becomes crystal clear? > > 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ührerin: Prof. Dr. Anke > Rita Kaysser-Pyzalla > > Sitz Berlin, AG Charlottenburg, 89 HRB 5583 > > Postadresse: > Hahn-Meitner-Platz 1 > D-14109 Berlin > > http://www.helmholtz-berlin.de > > --------------------------------------------------------------------------- > --- Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ ________________________________ 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ührerin: Prof. Dr. Anke Rita Kaysser-Pyzalla Sitz Berlin, AG Charlottenburg, 89 HRB 5583 Postadresse: Hahn-Meitner-Platz 1 D-14109 Berlin http://www.helmholtz-berlin.de |