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