RE: NT and non-NT types

[<dav...@di...>]

I really pleases that you see it that way.

I still a bit worried about the statement "Services SHOULD provide only EPICS V4 Normative Types" if something like the areaDetector application is classed as a service. Is the statement still correct? Unless areaDetector is the only high perform service  that would want its own data type that's going to make those other implementations non-compliant.

Dave.

From: Dalesio, Leo [mailto:da...@bn...]
Sent: 26 April 2013 12:09
To: Hickin, David (DLSLtd,RAL,DIA); epi...@li...
Subject: RE: NT and non-NT types

I think 5 is the best expression of the position.
I wanted us to focus on some basic set of types. I would state the goal for NT types is that we want to capture 80% of what is not supported in the DBR types.
And I agree that areaDetector is certainly the most compelling case.
I think that Nikolay is also working to handle an HDF5 blob as a standard NT type. That is an interesting way to capture anything else. That is a second compelling case.


________________________________
From: dav...@di...<mailto:dav...@di...> [dav...@di...]
Sent: Friday, April 26, 2013 6:35 AM
To: epi...@li...<mailto:epi...@li...>
Subject: NT and non-NT types
Thinking about image types has made me think about the status of NT types and perhaps more importantly non-NT types in EPICS V4.

When I gave a talk at Diamond in November there was some scepticism over normative types, in particular whether a small set of general purpose types will ever cover the range of applications.

Also the areaDetector type is aimed at a specific application. No other existing NT type could be used and it's clear that a general purpose image type won't do (not without a very large optional metadata section). AreaDetector is so widely-used and important that it's worth an NT type,  but I suspect across the gamut of potential users there smaller applications out there that will need something other than an existing NT type. And if we have a framework for constructing structured data of a wide variety of types arbitrary complexity can the community be persuaded to use a dozen or so types?

I had a look through the website for the official line on non-NT types and the clearest statement I found on their use as a whole across a facility was from the architectures document:

"To allow generic clients and prevent the unbounded spread of application-specific types, the EPICSv4 Working Group specifies a set of (about 10) Normative Types (Document) for common use cases. Examples are timestamped control data, relational database tables and multi-dimensional images. Generic tools will operate on Normative Types and it is expected that facilities will use Normative Types for the majority of applications."

I'm sure I've seen stronger statements from Bob and Greg on the preference for NT types. The only one I found though was from Greg's talk (http://epics-pvdata.sourceforge.net/talks/2012/EPICSV4SLAC_talk_Oct2012.pdf ):

"All general purpose clients MUST understand the EPICS V4 Normative Types,
to be considered EPICS V4 conforming
Services SHOULD provide only EPICS V4 Normative Types"

That seems clear for "general purpose clients", but not for the collective use of types and non-general clients across a facility. (And if  the areaDetector application is a service then do other similar "services" really have to all have to use only NT types?). With that in mind, which would you say is (or should be) our attitude to use of non-NT types in V4:

1.  The only types you should use in V4 are NT types. We might write specifications in such a way that you are not V4 compliant if you use a non NT type.

2. We really don't think you should use non-NT types. We won't write specifications that prohibit NT types, but we might write a reference implementation of a core library that means it can't be used with a non NT type (e.g. writing monitor code that can only monitor NT types).

3.  We don't think you should use non-NT types. The core libraries work with non-types, but there are standard tools that the working group develops that don't handle non-NT types and can't be easily extended to do so.

4. You're free to use non-NT types but we think you're making a mistake.  However we'll try not to do anything to prevent you.

5. We think we have provided a good collection of general purpose types but we understand that you might have an application that we haven't covered and requires some else. Look at what we've done with NT types, but feel free to write your own. We'll try to provide default behaviour for non-NT types and hooks for you to add custom handlers for non-NT types where possible to applications we develop and we encourage others to do the same. The type ID gives you a way of indentifying your type. Institutions can play in its own namespace. If a type becomes widely used it may be added to the NT types.

6. Do anything you like. Use a custom type each time if you like.


I don't think we're at 1 or 6, but I put them in  for completeness. I would say 5 would be the correct approach, but I get the impression that the official line is more 4 or even 3. I'm sure occasionally I've heard a view closer to 2 (which I strongly disagree with).

More concretely do things like PVManager allow you to add support for your own non-NT type (and CSS allow for the corresponding V-type).

Regards,

Dave.





--

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom





-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.

Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 

Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.

Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom