Details
-
New Feature
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
-
Platform Core
-
Not Needed
-
PAL is a new feature and should be documented as a whole when released. See pre-docs associated with the PAL API 5.y epic.
-
Needs Assessment
Description
The PAL API should have a method to register data type implementations. This should be allowed to allow an application to register application specific data types that exist in the top data type name space.
Usage of registering top namespace names should only be done if it is totally unacceptable to namespace the types. There are a few valid reasons:
- the data type will later migrate to puppet and when that occurs code should be backwards compatible (although it is possible to register an alias to make it backwards compatible - i.e. namespaces from the start, alias is the namespaced mapping to the non namespaced once the data type has moved).
- it is an integral part of an application where there conceptually is no natural module like namespace that can be used. (This could be the result of having painted yourself into a corner by having a module named after the application that is a puppet module that manages the application - and thus not being part of the application itself).
Registered data types must:
- comply with rules of being an Object data type. (They must serialize as objects)
- not come with logic that messes with the type inference making such objects appear as Scalar or other core data types
The implementor of a top name space data type must make a reservation for the name in the puppet specification's repository before starting to use that name. This to ensure that the name is not used for some other conflicting purpose by accident.
Thus, unless having very strong reasons to register a top name space data type - just don't!
Registering data types in a module name space (other than ::Puppet) is perfectly fine (while ensuring that it does not squat on a module namespace).
For a use case see: PUP-8190