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

Bob Arnson bob at firegiant.com
Thu May 6 10:10:06 PDT 2021 

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/

More information about the wix-devs mailing list