PFM Review / pfm_value_processor documentation and wonderings

[ygini]

In the pfm extension done at this time, there is the pfm_value_processor key.

This key is a decorator that help ProfileCreator to understand how to transform a value to keep things simple for the end user (for example when the format expect a time in the day represented in minutes since midnight).

So far I see 2 main issue with this key:

Missing documentation

Currently, there is no documentation of supported values and what they are expected to do.

I've been able to extract this list of values from the current repo:

• base642data
• designatedCodeRequirement2Data
• dockTileLabel
• dockTilePathType
• dockTileType
• hex2data
• plist2dict
• time2minutes
• weekdaysBitmask2Int
• x5002subjectArray

For each of them we should really wonder if it's the better data centric solution and if so, add a really clear documentation of what it is expected to do.

But for some (most?) of them, the second issue/statement/opinion apply

Situation where it would be better to introduce a new generic pfm_type

For some (most?) of those situation, the need would have been better answered with the introduction of a new pfm_type

For example in the energy saver manifest we can see:

<dict>
    <key>pfm_default</key>
    <integer>31</integer>
    <key>pfm_description</key>
    <string>The days on which the scheduled event occurs.</string>
    <key>pfm_name</key>
    <string>weekdays</string>
    <key>pfm_require</key>
    <string>always</string>
    <key>pfm_subkeys</key>
    <array>
        <dict>
            <key>pfm_description</key>
            <string></string>
            <key>pfm_name</key>
            <string>weekday</string>
            <key>pfm_range_list</key>
            <array>
                <integer>1</integer>
                <integer>2</integer>
                <integer>4</integer>
                <integer>8</integer>
                <integer>16</integer>
                <integer>32</integer>
                <integer>64</integer>
            </array>
            <key>pfm_range_list_titles</key>
            <array>
                <string>Monday</string>
                <string>Tuesday</string>
                <string>Wednesday</string>
                <string>Thursday</string>
                <string>Friday</string>
                <string>Saturday</string>
                <string>Sunday</string>
            </array>
            <key>pfm_title</key>
            <string>Weekday</string>
            <key>pfm_type</key>
            <string>integer</string>
        </dict>
    </array>
    <key>pfm_title</key>
    <string>Days to execute</string>
    <key>pfm_type</key>
    <string>integer</string>
    <key>pfm_type_input</key>
    <string>array</string>
    <key>pfm_value_processor</key>
    <string>weekdaysBitmask2Int</string>
</dict>

Where pfm_value_processor is set with value weekdaysBitmask2Int, expecting the processing app to present a list of day, and to compute them as a bit field.

For this usecase however it would have been more useful to define a new pfm_type named bitfield, it's a common type of data and would be great to support it directly without any decorators needed.

And with the addition of pfm_type bitfield you will also introduce pfm_raw_type with fixed string values representing the data type supported by plist file format.

Here, pfm_raw_type would have been set to integer

Another example still in the energy saver with the time of the day an action should be done:

						<dict>
							<key>pfm_date_style</key>
							<string>time</string>
							<key>pfm_default</key>
							<integer>0</integer>
							<key>pfm_description</key>
							<string>The time of day to perform the action.</string>
							<key>pfm_name</key>
							<string>time</string>
							<key>pfm_require</key>
							<string>always</string>
							<key>pfm_title</key>
							<string>Time of day</string>
							<key>pfm_type</key>
							<string>integer</string>
							<key>pfm_type_input</key>
							<string>date</string>
							<key>pfm_value_processor</key>
							<string>time2minutes</string>
						</dict>

Here again the best option would have been to add a pfm_type named time to avoid the use of decorators.

time as a generic type will need additional keys by the way to match different needs. Here is some basic ideas that need to be carefully developed to match all needs without complications:

• pfm_raw_type can realistically be integer or real and in some situation string or date
• pfm_time_representation could be introduced with values such as:
  • seconds
  • minutes
  • rounded-hours
  • fractional-hours
  • format
• where the format option would require to read pfm_time_format to export the time to a string raw type using standard time formating option (like %HH:%mm)

Opportunities behind those ideas

The introduction to pfm_raw_type could be interesting to also improve the situation in other usage, for example with MCX when 0 and 1 are used by a third part app to represent false and true.

Supporting pfm_type set to boolean with pfm_raw_type being integer would help to improve the situation from the data centric perspective:

• the represented value is a boolean
• but the required storage is an integer