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