How much control would you want a BAF to have over a BA? I could envision
having the BAF wanting to inject custom pages into the workflow or to modify
the UI state of the workflow.
I currently have a local implementation where the engine is downloading and
parsing an atom feed, doing a version comparison, and then allowing the BAF to
trigger an update. It feels like I had to cut pretty deep.
Changes include:
1. Added a function to the engine to download the feed.
2. Added a function to timeutil to parse RFC3339 compliant dates
3. Tweaked the atom parser to handle RFC3339 dates
4. Modified the existing DetectUpdate to do something if the BA returns
IDOK
5. Modified the BAF interface to have functions to process the command
line, and handle detect update begin, detect update complete
6. Added a BAF to trigger the update detection and call SetUpdate
7. Added an updatereplace page to wixstdba
As of now, I can shell to the bundle passing it /ba.update and it will prompt
the user for updating. When the user hits update, the engine downloads the new
bundle and runs it as expected.
I could really go for a virtual cup of coffee with Bob, Rob, and others to find
the best fit for these changes. I’d really love it if the changes could be
isolated to just the BA/BAF, but I don’t know of an “easy” way of exposing the
engine download functionality to a BA. I don’t want to expose internals to the
BA, but at the same time I don’t’ want to bloat the engine.
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Tuesday, October 15, 2013 11:54 AM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Thoughts on a self updating bundle
Sorry you are correct. I’m trying to remember why I didn’t implement a base
class, I am sure there was a really good reason at the time but I just can’t
remember why.
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 15 October 2013 16:25
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Thoughts on a self updating bundle
Correct me if I am wrong but IBootstrapperBAFunction is an interface with a
bunch of pure virtual functions defined in it. When you write a class which
implements this interface you must implement every method of the interface or
it won’t compile. I know your example BA functions could be used as a base,
but I was thinking something inside the engine should exist that implements all
the functions. If we had one, then I could write a BA function class that
derived from it and only overrode the methods I needed. This would allow new
methods to be added to the interface at will and not break existing BA function
builds.
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Tuesday, October 15, 2013 10:00 AM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Thoughts on a self updating bundle
I don’t think that is correct, you base your class on IBootstrapperBAFunction
and then only implement the functions you want.
Neil
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 15 October 2013 15:23
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Thoughts on a self updating bundle
The one thing I didn’t see was a true framework BA function base class. If we
have one that just implemented the default behavior for each function, assuming
anyone who writes their own BA function inherits from it , they would then not
have to change anything to get the updated code to compile. As is today, they
would need to implement any new interface members in order to be able to
compile.
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Monday, October 14, 2013 11:48 PM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Thoughts on a self updating bundle
Note: we can *add* methods to existing interfaces from backwards compatible
version to version. We do not try to maintain binary compatibility with WiX
toolset releases. In other words, if someone takes a new drop, they are
expected to rebuild all of their stuff against the new drop.
Now, when they recompile against a backwards compatible release everything
should just build and work. If not, then we should fix that as quickly as
possible.
On Mon, Oct 14, 2013 at 8:28 PM, Bob Arnson
<b...@joyofsetup.com<mailto:b...@joyofsetup.com>> wrote:
On 14-Oct-13 12:44, Hoover, Jacob wrote:
After looking into this over the weekend it seems interface
IBootstrapperBAFunction only has a small subset of possible “events” defined.
If we had OnDetectUpdateBegin in the interface then I think I could configure a
BA Function DLL to handle the app specific update checks and utilize the
existing SetUpdate call to update the bundle.
Seems reasonable.
The bigger question I have is around the IBootstrapperBAFunction, which
doesn’t have a GUID associated with it. I assume adding a method to this
interface would be considered a breaking change so it wouldn’t be accepted till
4.x, but sure would be nice to be able to version the interfaces.
It's not a proper COM object. So far, we haven't locked the BA interfaces; for
example, v3.7 added callbacks and method parameters.
At first I thought I could work around this without making breaking changes
to the interface, but as the Update element is “hidden” inside the Manifest it
isn’t accessible from a UX (without doing a bunch of voodoo to re-extract it
from the bundle exe).
Easy enough to add it to the BA manifest.
--
sig://boB
http://joyofsetup.com/
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
