[wix-devs] WIXBUG3704 - Allow access to persisted variables from related bundles

[Hoover, Jacob]

enum BURN_VARIANT_TYPE
{
    BURN_VARIANT_TYPE_NONE,
    BURN_VARIANT_TYPE_FORMATTED,
    BURN_VARIANT_TYPE_NUMERIC,
    BURN_VARIANT_TYPE_STRING, // when formatting this value should be used as is (don't continue recursively formatting).
    BURN_VARIANT_TYPE_VERSION,
};


As for the “easier” comment, I am just trying to reach a consensus so that I can continue to make progress.

Using regedit to modify data is the exception not the norm. Either way is doable, but obviously just modifying a string is going to be more natural. From a parsing standpoint, reading a number and switching on it would be more efficient.

We attempt to do some level of type coercion, as a variable type could change over time. Ex: a number can be read as a string, a version can be read as a string, a string (containing a numeric value) can be read as a number.

The API lets you probe the type, and also lets you attempt to read a variable of a given type.

The API is read only, you don’t own the variable, the original bundle does.

JSON is just a well known format, as opposed to encoding a magic character at the beginning of a string value. While it may be overkill, it would seem less custom than a format prefix.

Jacob

From: Ron Martin <cpuwzd at comcast.net>
Sent: Tuesday, May 4, 2021 1:52 PM
To: Hoover, Jacob <Jacob.Hoover at greenheck.com>; wix-devs <wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted variables from related bundles


Jacob,

I am hampered by incomplete knowledge of the context. You mention the engine. So I understand that the context
is that an installation, update, or uninstallation is in progress. The variables we are discussing are the ones that
can be modified by the user through the UI. I'm sure that the fixed set of types to which you refer can be deduced
from documentation, even if it is V3 documentation. I have not use Wix enough to have all of these types memorized
and I'm too lazy to look them up just for the purpose of this discussion.

So I was thinking outside the box. In fact, I was thinking without a box. I was willing to risk being shamed for making
unwarranted generalizations. My mental model of extensions does not benefit from a good understanding of all the
existing extensions or the intent of the architect(s) who created the extension mechanism. This is how I learn.

Of course, "much easier" is an opinion. I was trying to convey what I was thinking, not what I know. Perhaps I need
to find appropriate phrases to make this clearer when appropriate.

JSON is certainly worth considering. It has advantages for things like dates, versions, and paths: things that can
be pre-parsed.

I'm trying to imagine using regedit to modify such a registry entry (for debugging purposes, e.g.).
How would this experience compare between the two approaches?

If registry access is buried behind a Wix API, what features would look different and in what ways?

Would the API user ask for something by name and discover its type or would he ask for a thing of
a specific type by name and expect success or failure?

Similarly for writing, would he specify the type, name, and value? I think that in the writing case,
the choice is clear: The type of the value should supply all the necessary type information.

This seems to leave a loose end if null values are allowed, unless concrete static typed null objects
are used to indicate the type while specifying null value.

How does this affect the reading API?

How does the choice of prefixed strings vs. JSON strings affect the API and vice versa?

JSON does appear to have a leg up on validation, but if I understand JSON correctly, aren't all of
the attribute validations carried around in each instance rather than in a schema?

Respectfully,

Ron

________________________________
On 5/4/2021 1:02 PM, Hoover, Jacob wrote:

Unrecognized types?  The engine only supports a fixed set of types. Extensions can’t define additional variable types.

“Much easier” is an opinion.

If we really want to go the string route, why not use a JSON object in the registry?  We could then define it’s type and value, still live as a string, and have a well defined structure to validate against.

From: Ron Martin <cpuwzd at comcast.net><mailto:cpuwzd at comcast.net>
Sent: Tuesday, May 4, 2021 11:51 AM
To: Hoover, Jacob <Jacob.Hoover at greenheck.com><mailto:Jacob.Hoover at greenheck.com>; wix-devs <wix-devs at lists.wixtoolset.org><mailto:wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted variables from related bundles


Some of the things I thought about before making my suggestion:

If all of the strings we store in the registry (in this context) are differentiated by their first character,
many new types can be added later if necessary. A single switch statement can be used to separate the type. Unrecognized types can be passed through extensions.

The registry was not designed for flexibility or extensibility. Binary data can be organized for
straight-forward decoding, just as string data, but for debugging purposes, it is much easier
to decode strings than raw binary representation of multiple data structures.

Registry strings should not be used to store binary data in its raw form because there is a
potential for truncation when a null character is encountered. Registry strings are constrained
to UTF-16 with no encoding prefix.

Ron
On 5/4/2021 11:27 AM, Hoover, Jacob wrote:
easier to handle.

From: wix-devs <wix-devs-bounces at lists.wixtoolset.org><mailto:wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Ron Martin via wix-devs
Sent: Friday, April 30, 2021 2:49 PM
To: wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org>
Cc: Ron Martin <cpuwzd at comcast.net><mailto:cpuwzd at comcast.net>
Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted variables from related bundles
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.