The nice thing about interfaces is that we can add derivatives for new versions
much like COM does. Having to change callbacks or functions - like when you
need to pass additional detail - isn't really possible (especially once you've
released). Interaces and structs generally let you append methods/data onto the
end (vtbl for interfaces) safely.
Heath Stewart
Software Design Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths
From: r...@firegiant.com
To: wix-devs@lists.sourceforge.net
Date: Mon, 13 Oct 2014 08:44:25 +0000
Subject: Re: [WiX-devs] WIP 4149 and 4552
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> 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
------------------------------------------------------------------------------
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
