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
To: 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
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
