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]
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<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
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
