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> 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]
> *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> 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]
> *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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
