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

Wed May 5 13:37:25 PDT 2021

> Hide these letters from the API users

The goal is to expose the values to users that are not using any API,
unless we decide that that goal is not feasible. So it's not helpful right
now to be discussing how to modify the values to get rid of ambiguity
unless that is transparent to the non-API user. It is not transparent to
the non-API user if they have to remove a letter from the beginning of the
value.

On Wed, May 5, 2021 at 3:27 PM Ron Martin via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> 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/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>