[wix-devs] WIXBUG3704 - Allow access to persisted variables from related bundles
Ron Martin
cpuwzd at comcast.net
Fri May 7 14:29:34 PDT 2021
If I understand correctly, in V3, the blob is stored in a file and its
implementation is not published. Only the burn
engine is supposed to know how to access this information. In the
registry-based scenario, It would seem that
this access situation remains the same. Only the burn engine cares about
the format and structure of this data.
In an updating scenario, the burn engine would be considered to be a
"related bundle" with respect to the older
version's blob. This seems to mean that if it wanted to access this
information, it would need to use the string
interface. Perhaps you are thinking that the BA needs this access (on
install, update, or remove). It would also
have to use the string interface unless it can use the burn engine to
access the blob of the current installation.
I'm not sure of the ordering of these events, so I don't know if that
makes any sense.
We store this information in a variety of formats because we have a
contract with the author and that's what he
expects. Now we're moving the blob from a file to the registry. I'm not
sure what motivated that change. Perhaps
a document reference would help me here.
In any event, how much does it help the burn engine if it needs to
record the blob information in two formats?
If, in fact, the burn engine needs to access the information from a
related bundle, it might need to be able to
read the information in two formats.
Why not just store all the data as strings, with conversions applied on
access. Does the burn engine have
enough information from the UI to know what format is needed in each
case? What are the other complications.
Our contract with the author really doesn't require a particular storage
format, just an interface format.
If there is insufficient format information available in the burn
engine, I have already proposed two ways to
store the format information in the registry, one in-band and one
out-of-band.
Ron
On 5/7/2021 1:55 PM, Hoover, Jacob wrote:
>
> Would anyone have heartburn if the existing binary stream was stored
> in the registry as the default value (includes the count, included,
> name, type, value) and as an added bonus we would also store the
> string value of the persisted variables? Doing so, we could then
> expand the formatted strings, yet retain the unformatted value in the
> blob. Anything other than the original bundle would then use the new
> API to read related bundle variables as a string, and coerce them into
> their intended types.
>
> *From:* wix-devs <wix-devs-bounces at lists.wixtoolset.org> *On Behalf Of
> *Ron Martin via wix-devs
> *Sent:* Thursday, May 6, 2021 3:04 PM
> *To:* 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
>
> Good discussion!
>
> The term "related bundles" also conjures up an image of two bundles
> playing
> relative roles the way Reharper relates to VS. This would entail the
> ability to
> determine the registry base node of the related app (VS) by the given app
> (Resharper), perhaps via permanent GUID. This could, of course simply be
> a private agreement between the two bundled apps. But, if the
> installations
> can be moved around (including the registry entries) some help from Wix
> might
> be helpful. (You probably wouldn't Resharper's installer to have to
> open an instance
> of VS in order to complete its own installation.) Remember, Resharper
> and VS are
> being used as role models here, not as concrete applications.
>
> This is a totally separate issue but it might be a desirable follow-on
> feature.
>
> Ron
>
> On 5/6/2021 2:13 PM, Sean Hall via wix-devs wrote:
>
> > I liked the idea that everything is stored in REG_SZ and the storage of
> > types are an implementation detail that is undocumented and subject to
> > change. This allows the original bundle to access its own persisted
> > variables with type information, but requires everybody else to read
> it as
> > a string. The engine APIs could and should coerce that string just
> like it
> > does today with the existing variable methods.
> >
> > This means that how the types are stored is up to you. I thought that it
> > would be easiest to store it in binary format in the default value
> of the
> > registry key, basically the existing format but leave out the actual
> > values. I thought that the idea of having two values for every variable
> > would make it difficult to enumerate them.
> >
> > For BURN_VARIANT_TYPE_NONE, I'd have to dig into the code. My initial
> > thought is that there should be no value written for a variable with
> type
> > NONE. An empty string might work the same.
> >
> > On Thu, May 6, 2021 at 12:36 PM Hoover, Jacob
> <Jacob.Hoover at greenheck.com <mailto:Jacob.Hoover at greenheck.com>>
> > wrote:
> >
> >> So for each variable, a REG_SZ Value for the variable, and a REG_DWORD
> >> Value for the type? Would you be opposed to having 2 keys? IE,
> BURN_REGISTRATION_REGISTRY_UNINSTALL_KEY\%BUNDELID%\variables\type
> >> and
> BURN_REGISTRATION_REGISTRY_UNINSTALL_KEY\%BUNDELID%\variables\value.
> >>
> >>
> >>
> >> That would allow a simple enum of the values without an additional
> >> comparison on the values name.
> >>
> >>
> >>
> >> How would you propose handling REG_NONE/BURN_VARIANT_TYPE_NONE?
> >>
> >> Are we required to store BURN_VARIANT_TYPE_NUMERIC As a string, or
> could
> >> it be persisted as a REG_QWORD?
> >>
> >>
> >>
> >> *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:* Thursday, May 6, 2021 12:24 PM
> >> *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
> >>
> >>
> >>
> >> 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
> <mailto: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
> <mailto: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 <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
> >>>
> >>> 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
> <mailto: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
> <mailto:Jacob.Hoover at greenheck.com>>
> >>>> Sent: Thursday, 6 May, 2021 12:19
> >>>> To: WiX Toolset Developer Mailing List
> >>>> <wix-devs at lists.wixtoolset.org
> <mailto:wix-devs at lists.wixtoolset.org>>; Bob Arnson <bob at firegiant.com
> <mailto:bob at firegiant.com>>
> >>>> 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
> >>>>
> >>>> 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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>>
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%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: Thursday, May 6, 2021 12:26 AM
> >>>> To: Bob Arnson <bob at firegiant.com<mailto:bob at firegiant.com
> <mailto:bob at firegiant.com%3cmailto:bob at firegiant.com>>>; WiX
> >>>> Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:%0b>>>
> <wix-devs at lists.wixtoolset.org%3cmailto:%0b
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> 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
> <mailto:cpuwzd at comcast.net%3cmailto: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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>>
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%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: Wednesday, 5 May, 2021 19:37
> >>>>> To: Bob Arnson via wix-devs <wix-devs at lists.wixtoolset.org<mailto:
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:%0b>>>
> <wix-devs at lists.wixtoolset.org%3cmailto:%0b
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> 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
> <mailto:cpuwzd at comcast.net%3cmailto: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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>>
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> 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%0b>>>
> <wix-devs at lists.wixtoolset.org%0b
> <mailto:wix-devs at lists.wixtoolset.org%0b>>> > <
> >> mailto:wix-devs at lists.wixtoolset.org
> <mailto:wix-devs at lists.wixtoolset.org> <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
> <mailto:r.sean.hall at gmail.com%3cmailto: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>
> >>> <mailto:
> <mailto:%0b>>> <%0b>> > 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><
> >>>> 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 <mailto:bob at firegiant.com%3cmailto>:
> >> <bob at firegiant.com%3cmailto:%0b
> <mailto:bob at firegiant.com%3cmailto:%0b>>> > 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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>>
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> 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
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.or%0b>>>
> <wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.or%0b
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.or%0b>>>
> >>>>>> g>>
> >>>>>>> Cc: Sean Hall
> >>>>>>> <r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com
> <mailto:r.sean.hall at gmail.com%3cmailto: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
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto: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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>>
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> 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
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.o%0b>>>
> <wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.o%0b
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.o%0b>>>
> >>>>>>> rg>>;
> >>>> Ron Martin <cpuwzd at comcast.net<mailto:cpuwzd at comcast.net
> <mailto:cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net>>>
> >>>>>>>> Cc: Rob Mensching <rob at firegiant.com<mailto:rob at firegiant.com
> <mailto:rob at firegiant.com%3cmailto: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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>>
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> 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
> <mailto:cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net>>>;
> >>>> wix-devs <
> >>>>>>>>
> wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.or
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.or>
> >>>>>>>> g>>
> >>>>>>>> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:
> <mailto:Jacob.Hoover at greenheck.com%3cmailto:%0b>>>
> <Jacob.Hoover at greenheck.com%3cmailto:%0b
> <mailto:Jacob.Hoover at greenheck.com%3cmailto:%0b>>> >
> 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
> <mailto:cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net>>>
> >>>>>>>> Sent: Tuesday, May 4, 2021 11:51 AM
> >>>>>>>> To: Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:
> <mailto:Jacob.Hoover at greenheck.com%3cmailto:%0b>>>
> <Jacob.Hoover at greenheck.com%3cmailto:%0b
> <mailto:Jacob.Hoover at greenheck.com%3cmailto:%0b>>> >
> 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
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto: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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>>
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> wix-devs-bounces at lists.wixtoolset.org>><mailto
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3e%3e%3cmailto>:
> >>>> <mailto:%0b <%0b <mailto:%0b%20%3c%0b>>>>>>>
> wix-devs-bounces at lists.wixtoolset.org<mailto
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto>:
> >>>> 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
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.or>
> >>>>>>>> g
> >>>> <mailto:wix-devs at lists.wixtoolset.org%
> <mailto:wix-devs at lists.wixtoolset.org%25%0b>>>
> <wix-devs at lists.wixtoolset.org%25%0b
> <mailto:wix-devs at lists.wixtoolset.org%25%0b>>> >
> >> 3cmailto:wix-devs at lists.wixtoolset.org>>
> >>>>>>>> Cc: Ron Martin <cpuwzd at comcast.net<mailto:cpuwzd at comcast.net
> <mailto:cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net%0b>>>
> <cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net%0b
> <mailto:cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net%0b>>> > >><
> >> mailto:cpuwzd at comcast.net <mailto:cpuwzd at comcast.net>
> <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><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/>
> >>>>>>>>
> >>>>>>> __________________________________________________________________
> >>>>>>> __ 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/>
> >>>>> ____________________________________________________________________
> >>>>> 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/ <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/ <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.
>
More information about the wix-devs
mailing list