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

Ron Martin cpuwzd at comcast.net
Wed May 5 13:27:01 PDT 2021 

Deciding to prefix a version string with a 'v' is kind of where I 
started. To get rid of ambiguity,
pick an appropriate(?) letter for each  the other types to be encoded as 
strings. Hide these
letters from the API users on both sides while providing a different 
means of specifying the
intended type on writing and the desired type on reading. All 
conversions and error checking
to be behind the cloak, thus treating the registry as a communication 
medium with storage.

I'd like to see side-by-side examples of all alternative registry 
encodings under consideration.

On 5/5/2021 4:11 PM, Sean Hall via wix-devs wrote:
>>   What if Versions were stored as a string prefixed with a `v`
> I can't see how that would work because it needs to unambiguous about what
> the type of the variable is and as you pointed out Strings beginning with
> "v" would be ambiguous. Trying to disambiguate it would break the
> transparency and require code to get the raw value. Unless we go with Bob's
> idea about storing everything as strings and make the person getting the
> variable's value tell the API what the type is.
>
> On Wed, May 5, 2021 at 2:58 PM Rob Mensching <rob at firegiant.com> wrote:
>
>> What if Versions were stored as a string prefixed with a `v`. Isn't that
>> how versions are defined in Burn code already? It's not perfect for words
>> that start with "v" so just tossing out the idea... really would rather see
>> formatted and versions as a string than binary.
>>
>> -----Original Message-----
>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
>> Hall via wix-devs
>> Sent: Wednesday, May 5, 2021 12:53 PM
>> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
>> Cc: Sean Hall <r.sean.hall at gmail.com>
>> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted variables
>> from related bundles
>>
>>   I think everyone agrees that none of the variable types can share the
>> same registry type. I think everybody agrees on these mappings:
>>
>> BURN_VARIANT_TYPE_NONE -> REG_NONE
>> BURN_VARIANT_TYPE_NUMERIC -> REG_QWORD
>> BURN_VARIANT_TYPE_STRING -> REG_SZ
>>
>> So the only remaining thing is where do the other variable types go?
>>
>> BURN_VARIANT_TYPE_FORMATTED
>> BURN_VARIANT_TYPE_VERSION
>>
>> Is it worth subverting the other registry types like REG_EXPANDED_SZ and
>> REG_MULTI_SZ to mean something other than what they normally mean so that
>> people can read the values without any code? Or do we give up on that
>> transparency and just stick them in a binary format with the REG_BINARY
>> type?
>>
>> On Wed, May 5, 2021 at 2:35 PM Ron Martin via wix-devs <
>> wix-devs at lists.wixtoolset.org> wrote:
>>
>>> If there is a valid means of substitution in this context, whether it
>>> be from environment variables or other sources available to the
>>> engine, the result of the expansion could reasonably be expected to be
>>> a function the bundle for which the expansion is being done.
>>> Otherwise, I would think that all expansions would be done in the
>>> context of the "owning bundle" and the formatted strings would
>>> effectively become ordinary strings.
>>>
>>> Any distinction that is required can be handled by either of the two
>>> schemes we've been discussing (and others).
>>>
>>> I  think that, in some sense, formatted strings need to be self aware
>>> substrings of ordinary strings that might be expanded if they were
>>> formatted strings should not be expanded based on this content. Any
>>> type coercion that might be performed based on the type requested
>>> being different from the stored type should take this into account.
>>> If formatted strings can be requested and available, they should not
>>> be expanded. (I assume that, in this case, the train has already left
>>> the station and that there is no place further down the line to do the
>>> expansion, so this case is moot.) In the other direction, variables
>>> stored as formatted strings can be expanded to ordinary strings before
>>> converting to other types. The remaining types can be converted
>>> directly when it makes sense or they can be converted to strings and
>>> then to their requested types. It is in this last group of conversions
>>> that I would expect the most conversion errors to be detected.
>>>
>>> Is the purpose of a "none" value to replace an ordinary value when you
>>> wish to essentially undefine it? What advantage does this yield over
>>> actually undefining the value? My understanding of "ifdef" in other
>>> Wix contexts is that zero and null are the only values that are
>>> considered undefined.
>>>
>>> Bottom line somebody needs to make a call so you can get your work done.
>>> I never meant to tie you up, but I
>>> do think that this topic has needed some discussion so that the next
>>> time it comes up, the reasons for our choices will be on the record.
>>>
>>> Ron
>>>
>>> On 5/5/2021 1:56 PM, Hoover, Jacob wrote:
>>>> Was hoping Sean would respond on this…  It is my understanding that
>>>> the formatted string is expanded at runtime by the engine, when a
>>>> variable is evaluated.
>>>>
>>>> There is concern that a string variable which is restored as
>>>> formatted, that it could get variable expansion that it would not
>>>> have, Also if a variable was formatted but is restored as a string
>>>> that it would no longer get expansion.
>>>>
>>>> *From:* wix-devs <wix-devs-bounces at lists.wixtoolset.org> *On Behalf
>>>> Of *Ron Martin via wix-devs
>>>> *Sent:* Tuesday, May 4, 2021 2:42 PM
>>>> *To:* Bob Arnson <bob at firegiant.com>; WiX Toolset Developer Mailing
>>>> List <wix-devs at lists.wixtoolset.org>
>>>> *Cc:* Ron Martin <cpuwzd at comcast.net>
>>>> *Subject:* Re: [wix-devs] WIXBUG3704 - Allow access to persisted
>>>> variables from related bundles
>>>>
>>>> In what context is BURN_VARIANT_TYPE_FORMATTED expanded? Would it be
>>>> stored in one context and interpreted in another? What can change in
>>>> the context between creation and use?
>>>>
>>>> I'm just trying to get my head around the real issues.
>>>>
>>>> Ron
>>>>
>>>> On 5/4/2021 3:17 PM, Bob Arnson wrote:
>>>>> BAs already have to specify a type when getting a variable value
>>>> from the engine. The engine knows a variable's type when it persists
>>>> the value -- so what if it required a variable to exist so it had
>>>> the type when reading it? At that point, the registry type could be
>>>> REG_SZ for everything, no encoding necessary.
>>>>> -----Original Message-----
>>>>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org
>>>> <mailto:wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of Rob
>>>> Mensching via wix-devs
>>>>> Sent: Tuesday, 4 May, 2021 14:13
>>>>> To: WiX Toolset Developer Mailing List
>>>> <wix-devs at lists.wixtoolset.org
>>>> <mailto:wix-devs at lists.wixtoolset.org>>; Ron Martin
>>>> <cpuwzd at comcast.net <mailto:cpuwzd at comcast.net>>
>>>>> Cc: Rob Mensching <rob at firegiant.com <mailto:rob at firegiant.com>>
>>>>> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted
>>>> variables from related bundles
>>>>> Sorry, I mentioned encoding the values in a string the way the
>>>> Windows Installer does in the Registry table to include it as an
>>>> option. I do not have a strong opinion that it is the best way to go
>>>> (although encoding in JSON or XML seems way overkill). Trying to
>>>> reuse the built-in registry types is noble if you can resolve all
>>>> the issues Sean was discussing.
>>>>> -----Original Message-----
>>>>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org
>>>> <mailto:wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of Hoover,
>>>> Jacob via wix-devs
>>>>> Sent: Tuesday, May 4, 2021 10:02 AM
>>>>> To: Ron Martin <cpuwzd at comcast.net <mailto:cpuwzd at comcast.net>>;
>>>> wix-devs <wix-devs at lists.wixtoolset.org
>>>> <mailto:wix-devs at lists.wixtoolset.org>>
>>>>> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com
>>>> <mailto:Jacob.Hoover at greenheck.com>>
>>>>> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted
>>>> variables from related bundles
>>>>> 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>><mailto:
>>> 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
>>>> <mailto:wix-devs at lists.wixtoolset.org%
>>> 3cmailto:wix-devs at lists.wixtoolset.org>>
>>>>> Cc: Ron Martin <cpuwzd at comcast.net
>>>> <mailto:cpuwzd at comcast.net>><mailto: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.
>>>>> __________________________________________________________________
>>>>> __ WiX Toolset Developer Mailing List provided by FireGiant
>>>> http://www.firegiant.com/ <http://www.firegiant.com>
>>>> ____________________________________________________________________
>>>>> WiX Toolset Developer Mailing List provided by FireGiant
>>>> http://www.firegiant.com/ <http://www.firegiant.com/>
>>>> ____________________________________________________________________
>>>> WiX Toolset Developer Mailing List provided by FireGiant
>>>> http://www.firegiant.com/ <http://www.firegiant.com/>
>>>>
>>>> NOTE: This email was received from an external source. Please use
>>>> caution when opening links or attachments in the message.
>>>>
>>> ____________________________________________________________________
>>> WiX Toolset Developer Mailing List provided by FireGiant
>>> http://www.firegiant.com/
>>>
>> ____________________________________________________________________
>> WiX Toolset Developer Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/

More information about the wix-devs mailing list