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

Thu May 6 10:24:28 PDT 2021

I think storing each variable in a value as type REG_SZ with the variable
types stored separately is simple and easy and enables outside use. Do you
agree?

On Thu, May 6, 2021 at 12:10 PM Bob Arnson <bob at firegiant.com> wrote:

> If the values are trivial to read (e.g., with RegistrySearch) then it's
> trivial to handle across versions. I don't want to have to maintain
> multiple versions of de-persisting variables but not being able to upgrade
> your version of WiX ever without losing that feature? That's not good. So
> make it simple. KISS.
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Thursday, 6 May, 2021 13:06
> 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 have never understood the idea that we will support a bundle being able
> to get any other bundle's persisted variables, but somehow have the ability
> to change how we actually do that. Once you ship a bundle, it's out in the
> world. It will persist its variables according to the version of Burn it
> was built with. If the format changes later, newer bundles won't be able to
> access its persisted variables. I must be missing something.
>
> On Thu, May 6, 2021 at 11:56 AM Bob Arnson via wix-devs <
> wix-devs at lists.wixtoolset.org> wrote:
>
> > When this first came up, I said something along the lines of “if it’s
> > easy to store the variables in registry values, then we should do that
> > because it enables outside use.” Key is “if it’s easy” – enabling
> > outside use isn’t a requirement, just a nice bonus.
> >
> > From: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> > Sent: Thursday, 6 May, 2021 12:19
> > To: WiX Toolset Developer Mailing List
> > <wix-devs at lists.wixtoolset.org>; Bob Arnson <bob at firegiant.com>
> > Cc: Ron Martin <cpuwzd at comcast.net>
> > Subject: RE: [wix-devs] WIXBUG3704 - Allow access to persisted
> > variables from related bundles
> >
> > One could go to the opposite end of the spectrum and say let’s just
> > store the existing variable blob as a single binary value.  The format
> > remains undocumented, and the only way you access it is via DUtil.
> >
> > Asking for API’s in other languages/frameworks is a bit off putting.
> > If you are installed by a bundle, you are using a Managed/Native BA.
> > You have the ability at install/maint/removal to get previous install
> variables.
> > The goal isn’t to store the applications configuration and provide an
> > API for any application to access it, its to allow a bundle’s config
> > to be persisted across reboots, and to allow bundle v 1.1 to read in
> > what options the user chose when they installed bundle v 1.0.
> >
> >
> > 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: Thursday, May 6, 2021 12:26 AM
> > To: Bob Arnson <bob at firegiant.com<mailto:bob at firegiant.com>>; WiX
> > Toolset Developer Mailing List <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
> >
> > That's what I'm suggesting. It's more in keeping with the way the
> > registry is designed to be used.
> >
> > In the following, when I refer to an unspecified app, you should be
> > thinking that this "app" is Wix. I'm trying to leave as many options
> > open as I can think of, so don't be thinking, "We don't need this
> > generality in Wix". Think of using only as much as you need. Just keep
> > in mind that if the situation changes, these options can still be
> > used.
> >
> > The usual situationis that you have a name, consisting of a base path
> > plus the relative path to the registry key. Once you access the
> > key,you can get as many attributes as are useful. One (or more) of the
> > attributes can be used to store the app-specific type of the value (or
> > values) stored. The value, as a function of the app-specific type, can
> > be stored in one (or more) attributes. The registry value types to be
> > used for each attribute are determined by contract and can be
> > dependent on the values of other attributes. The contract can be as
> > simple or as complex as necessary to do the job at hand. It can
> > specify the use and method of use of versioning, whether values can be
> > stored in multiple app-specific types simultaneously or only one at a
> > time.
> >
> > Conversions are ultimately the responsibility of the reader. A helper
> > may be provided in C for convenience.
> > Its source code  can serve as a guide for readers written in other
> > languages.
> >
> > This is what I meant. Take it for what its worth. I can flesh it out
> > some more if your imagination hasn't already run away with you.
> >
> > Ron
> >
> >
> > On 5/5/2021 10:24 PM, Bob Arnson wrote:
> > > Just to clarify, you're saying each variable should have two
> > > registry
> > values, one with the variable's value and one with its type?
> > >
> > > -----Original Message-----
> > > 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: Wednesday, 5 May, 2021 19:37
> > > To: Bob Arnson via wix-devs <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
> > >
> > > Perhaps a little less fugly would be to use two different values of
> > > the
> > same registry key (say, for sake of argument, "Type" and "Value"), so
> > that a single name applies to both. You could even add a "Version"
> > value to the mix, but I'd lean toward versioning the names of the
> > types ("Version.V1", "Version.V2", perhaps) if a new direction is
> desirable in the future.
> > >
> > > Ron
> > >
> > > On 5/5/2021 6:55 PM, Bob Arnson via wix-devs wrote:
> > >> I don’t see any dutil changes in Jacob's repos or draft PRs on
> > wixtoolset...
> > >>
> > >> As I didn't know a variable's type could be changed, it's obviously
> > >> not important (or I would've known, right?!). 😊
> > >>
> > >> We could always store the variable values in individual REG_SZ
> > >> values
> > then encode their types separately. E.g.: _BurnVariables (REG_SZ) =
> > "Var1=0;Var2=1;Var3=2".
> > >>
> > >> Fugly but effective.
> > >>
> > >> -----Original Message-----
> > >> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:
> > wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of
> > >> Sean Hall via wix-devs
> > >> Sent: Wednesday, 5 May, 2021 18:09
> > >> To: WiX Toolset Developer Mailing List
> > >> <wix-devs at lists.wixtoolset.org
> > <mailto:wix-devs at lists.wixtoolset.org>>
> > >> Cc: Sean Hall <r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com>>
> > >> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted
> > >> variables from related bundles
> > >>
> > >> Since this always happens when we send this amount of mail in one
> > >> day -
> > you can unsubscribe from this list by sending an email with the
> > subject "Unsubscribe" to wix-devs-unsubscribe at lists.wixtoolset.org
> <mailto:
> > wix-devs-unsubscribe at lists.wixtoolset.org>, the link is at
> > https://wixtoolset.org/documentation/mailinglist/<
> > https://wixtoolset.org/documentation/mailinglist>.
> > >>
> > >> 2. No, I was assuming Jacob's existing dutil API. If they're all
> > persisted as strings, then the dutil API could be changed to only
> > return strings.
> > >>
> > >> But only storing them as strings depends on 1. The engine needs to
> > >> know
> > the types, and if the type isn't stored with the persisted variables
> > then it would have to restrict the variable from changing its type
> > from the manifest.
> > >>
> > >> On Wed, May 5, 2021 at 4:54 PM Bob Arnson <bob at firegiant.com<mailto:
> > bob at firegiant.com>> wrote:
> > >>
> > >>> 1. Didn’t know that was a thing, so I have no opinion on whether
> > >>> that's a good/bad/indifferent restriction.
> > >>> 2. Does dutil need to care? BundleGetBundleInfo returns only
> > >>> strings today, so I'd assume that'd be good enough for non-BA
> > >>> users. BAs could request explicit types and we haven't discussed
> > >>> any kind of authoring level of support for this feature.
> > >>>
> > >>> -----Original Message-----
> > >>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:
> > wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of
> > >>> Sean Hall via wix-devs
> > >>> Sent: Tuesday, 4 May, 2021 15:33
> > >>> To: WiX Toolset Developer Mailing List
> > >>> <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.or
> > >>> g>>
> > >>> Cc: Sean Hall
> > >>> <r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com>>
> > >>> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted
> > >>> variables from related bundles
> > >>>
> > >>> That would require that persisted variables can't have their type
> > >>> dynamically changed at runtime. Maybe this is reasonable, but it's
> > >>> a restriction that doesn't exist today.
> > >>>
> > >>> That doesn't really work when querying outside of the original
> bundle.
> > >>> I think it can be argued that the querier should be required to
> > >>> ask for a specific type instead of tracking it in the registry,
> > >>> but that would require the dutil API to know how to do Burn variable
> coercion.
> > >>>
> > >>> On Tue, May 4, 2021, 14:17 Bob Arnson via wix-devs <
> > >>> wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org
> > >>> >>
> > 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.o
> > >>>> rg>>;
> > 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.or
> > >>>> g>>
> > >>>> 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.or
> > >>>> g>>
> > >>>> 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:
> > <mailto:%0b>>>>> 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.or
> > >>>> g
> > <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>
> > >>>> 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/
> > >>>> _________________________________________________________________
> > >>>> ___ 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/
> > > ____________________________________________________________________
> > > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > 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/
>