Yes, something very much like that. Assuming authentication is a callback as
well then it does seem that download and authentication need their own void
pointer contexts (or share a single context which may be okay... just means the
caller maybe has to put more in their context struct).
Are any of those parameters optional? Seems at least the context and maybe the
authentication routine could be NULL. In that case, use "__in_opt" as the
annotation.
Very exciting to see some new faces doing some bigger work in the WiX toolset.
<smile/>
From: Blair Murri [mailto:os...@live.com]
Sent: Saturday, October 19, 2013 8:07 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] RFC: Download functionality
Is pAuthenticationContext passed to pAuthentication, to pCallback, or to both?
Disclaimer, I have not looked in the sources to see how the current
download/authentication is being handled in the engine.
________________________________
From: jacob.hoo...@greenheck.com<mailto:jacob.hoo...@greenheck.com>
To: wix-devs@lists.sourceforge.net<mailto:wix-devs@lists.sourceforge.net>
Date: Sat, 19 Oct 2013 15:00:46 +0000
Subject: Re: [WiX-devs] RFC: Download functionality
Something more along the lines of?
HRESULT DAPI WininetDownloadUrl(
__in DOWNLOAD_SOURCE* pDownloadSource,
__in DWORD64 dw64AuthoredDownloadSize,
__in LPCWSTR wzDestinationPath
__in DOWNLOAD_CACHE_CALLBACK* pCallback,
__in LPAUTHENTICATION_ROUTINE pAuthentication,
__in LPVOID pAuthenticationContext,
);
And I got around the bundle version by simply reading the variable from the
engine.
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Saturday, October 19, 2013 1:40 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] RFC: Download functionality
1. We use "pContext" pointers regularly to allow the provider of a
callback to pass itself data. I would probably reorder arguments to that
function a bit but totally looks reasonable to me.
2. Yes, the UX manifest is hidden away and we duplicate stuff in the
BootstrapperApplicationData.xml. We do this so we can optimize (i.e. radically
change) it and only the Burn engine needs updating (for example, it could
become a binary blob). The BootstrapperApplicationData.xml should be documented
(probably isn't <sigh/>) and can be extended as we see fit.
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Friday, October 18, 2013 3:51 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] RFC: Download functionality
Hmm, I was able to gut it out of the engine and put it into dutil. I haven't
pushed yet, but was wondering about the general feeling of passing untyped
pointers was.
Ex:
HRESULT DAPI WininetDownloadUrl(
__in LPVOID pData,
__in LPAUTHENTICATION_ROUTINE pAuthentication,
__in DOWNLOAD_CACHE_CALLBACK* pCallback,
__in DOWNLOAD_SOURCE* pDownloadSource,
__in DWORD64 dw64AuthoredDownloadSize,
__in LPCWSTR wzDestinationPath
);
The reason for the untyped pointer was the only thing that really cared about
it was the Authentication callback, so I abstracted that away and I'm allowing
the caller to define what context he needs for authentication. This allows the
engine to pass a pointer a struct containing the UX, and other IDs, while a BAF
can pass the information it cares about (and each have their own independent
auth routine). I also moved the structs needed and renamed them to not be burn
specific, and used typedefs in the engine to allow the BURN_* types to function.
With this setup, I am 99% of the way there where the engine changes originally
committed have been ported to a BAF. My final hold up is finding a clean way to
get the bundle version from the UX manifest. Was it an intentional decision to
not expose the UX manifest to the BA?
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Thursday, October 17, 2013 1:21 PM
To: Windows Installer XML toolset developer mailing list
Subject: [WiX-devs] RFC: Download functionality
After today's triage, I'm looking to start a discussion on migrating the burn
engine's download functionality to balutil so that BA's can utilize the same
code without having to go through the engine.
After a speedy review, it looks like the amount of engine specific hooks is
limited to the UX window handle and an on error callback. If it is that simple
I may try migrating this myself.
Thanks,
Jacob
------------------------------------------------------------------------------
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
