Yeah, I’m torn on the interface thing. A while ago, I was with you on the use
of interfaces. However, trying to enhance Burn in WiX v3.x has given me pause
and I’m back to re-evaluating options.
However, dutil is obviously a very old school Win32 like API. Interfaces there
are generally surprising. Consistency has a lot of value when maintaining the
code over time. <smile/>
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Sean Hall [mailto:r.sean.h...@gmail.com]
Sent: Sunday, October 12, 2014 6:27 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIP 4149 and 4552
I'll go with callbacks then. I still prefer an interface, but maybe that's
just my managed code bias showing.
On Sat, Oct 11, 2014 at 7:42 PM, Rob Mensching
<r...@firegiant.com<mailto:r...@firegiant.com>> wrote:
Yes, exactly! So thmutil isn’t tied to one way of evaluating conditions.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Sean Hall [mailto:r.sean.h...@gmail.com<mailto:r.sean.h...@gmail.com>]
Sent: Saturday, October 11, 2014 9:23 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIP 4149 and 4552
The motivation for all this work is for thmutil/thmviewer. I'm proposing that
thmutil gets access to variables/conditions through the new interface, since it
needs the same restricted access. The BA can't pass the IBootstrapperEngine
since the interface is defined in Burn, so how would you like to do it -
callbacks?
On Sat, Oct 11, 2014 at 1:48 AM, Rob Mensching
<r...@firegiant.com<mailto:r...@firegiant.com>> wrote:
Ahh, okay. I see it slightly differently. The Burn engine controls the
variables (using the handle pattern should be fairly natural there). It can set
them, read them, do as it needs (it controls the handle).
The BA on the other hand is “foreign code”. The engine provides an interface to
access a very controlled set of things the engine feels comfortable sharing.
Therefore, the engine does extra work when the BA makes a request that
translates the BA’s request into engine concepts.
Thus the BA’s don’t use varutil/condutil at all. They use the Burn engine. The
Burn engine uses varutil/condutil. In fact, if a BA linked in dutil.lib
(totally reasonable) and started using varutil/condutil, that would be
completely fine. However, the BA would be with a completely different set of
variables because the it would have a different handle than the Burn engine
does. Again, this is very desirable.
I think the key thing I believe is the fact that Burn treats it’s BA as
“foreign code”. That is why we have the interfaces to clearly demarcate Burn
from BA.
Does that make sense? Did I miss some part of your argument that makes all the
above just rambling? <smile/>
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Sean Hall [mailto:r.sean.h...@gmail.com<mailto:r.sean.h...@gmail.com>]
Sent: Friday, October 10, 2014 7:17 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIP 4149 and 4552
I think what I'm trying to say is that there are currently two different
consumers of variables/conditions: the engine and the BA. The BA's API
consists of the methods that I'm proposing to move to an interface defined in
dutil. The engine's API is in condition.h and variable.h. This separation is
required so that built-in variables can't be set by the BA (and there might be
other reasons). So if varutil/condutil was implemented using handles, there
would have to be some kind of restricted handle because the engine's not going
to give the BA its unrestricted handle.
I prefer exposing the restricted API as a new interface over having two kinds
of handles. Either way, varutil.h and condutil.h could change without
requiring the Burn interfaces to change.
On Fri, Oct 10, 2014 at 2:57 PM, Rob Mensching
<r...@firegiant.com<mailto:r...@firegiant.com>> wrote:
I don’t quite follow. Can you clarify a bit so I don’t say things based on
wrong conclusions. <smile/>
Note: I’m less concerned about maintaining burn’s variable.cpp and more about
making dutil’s varutil.cpp (I’m guessing the name will be something like that)
look like the rest of dutil. I’m also not thrilled about introducing more
interface patterns to Burn… partially because I’m entertaining an idea to use a
WndProc callback pattern to Bas and build the IBootstrapperApplication as an
*optional* thing on top of that (but this is still a mostly unbaked idea).
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Sean Hall [mailto:r.sean.h...@gmail.com<mailto:r.sean.h...@gmail.com>]
Sent: Friday, October 10, 2014 11:16 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WIP 4149 and 4552
Some quick thoughts:
Part of the work I did for secure variables was making Burn go through the
variable methods instead of accessing the variants directly. I was trying to
hide the variants with the IVariableStore interface, I can't remember if that's
going to be possible if we keep variable.h. Could we do both the COM interface
and variable.h?
On Fri, Oct 10, 2014 at 12:26 PM, Rob Mensching
<r...@firegiant.com<mailto:r...@firegiant.com>> wrote:
Cool. I definitely like the proposal to pull variables and conditions to
dutil. We probably should have done that when first creating Burn.
1. However, I don’t think we should change the variable (or conditions)
“API” to be an interface pattern. I think we should stick with the most common
pattern in dutil using the handle pattern.
2. I think we should keep the IBootstrapperEngine interface “purely
Burn”. We don’t want to have it inherit from interfaces that are not
specifically in Burn since there are extra compatibility issues to consider in
Burn. For example, compatibility issues that might not be considered when
updating “varutil.h” in dutil.
I think we should keep the burn\engine\variable.h “interface” basically
untouched in the move to dutil (obviously rename structs and such so they don’t
say “BURN” in them and no Burn related manifest XML parsing <smile/>).
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Sean Hall [mailto:r.sean.h...@gmail.com<mailto:r.sean.h...@gmail.com>]
Sent: Thursday, October 9, 2014 8:42 PM
To: WiX toolset developer mailing list
Subject: [WiX-devs] WIP 4149 and 4552
I submitted a pull request with new WIPs that are trying to allow customizing
wixstdba based on variables. We've discussed a lot of this before, so
hopefully there aren't any surprises.
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
