James wrote:
I thought the idea was to implement winhttp and then implement wininet on top of winhttp. Why are you importing wininet?
As of January, Hans was still talking about implementing winhttp on top of wininet ( http://www.winehq.org/pipermail/wine-devel/2008-January/062172.html http://www.winehq.org/pipermail/wine-devel/2007-August/058420.html )
It's not clear one can fully implement either wininet on top of winhttp or vice versa. We will probably need some code duplication or private interfaces eventually.
Building winhttp on top of wininet lets us develop on trunk and is probably the fastest path to making a bunch of applications happy, isn't it? That's the way I'm leaning, anyway. - Dan
On Fri, Jul 18, 2008 at 9:11 AM, Dan Kegel dank@kegel.com wrote:
James wrote:
I thought the idea was to implement winhttp and then implement wininet on top of winhttp. Why are you importing wininet?
As of January, Hans was still talking about implementing winhttp on top of wininet ( http://www.winehq.org/pipermail/wine-devel/2008-January/062172.html http://www.winehq.org/pipermail/wine-devel/2007-August/058420.html )
It's not clear one can fully implement either wininet on top of winhttp or vice versa. We will probably need some code duplication or private interfaces eventually.
Building winhttp on top of wininet lets us develop on trunk and is probably the fastest path to making a bunch of applications happy, isn't it? That's the way I'm leaning, anyway.
Sure, I was just going by the words of those I considered more experienced than me in this area, and my impression was that wininet was a subset of the functionality found in winhttp, but it seems that's not the case. It would not surprise me at all if the Windows implementations of these two modules are separate.
James Hawkins wrote:
On Fri, Jul 18, 2008 at 9:11 AM, Dan Kegel dank@kegel.com wrote:
James wrote:
I thought the idea was to implement winhttp and then implement wininet on top of winhttp. Why are you importing wininet?
As of January, Hans was still talking about implementing winhttp on top of wininet ( http://www.winehq.org/pipermail/wine-devel/2008-January/062172.html http://www.winehq.org/pipermail/wine-devel/2007-August/058420.html )
It's not clear one can fully implement either wininet on top of winhttp or vice versa. We will probably need some code duplication or private interfaces eventually.
Building winhttp on top of wininet lets us develop on trunk and is probably the fastest path to making a bunch of applications happy, isn't it? That's the way I'm leaning, anyway.
Sure, I was just going by the words of those I considered more experienced than me in this area, and my impression was that wininet was a subset of the functionality found in winhttp, but it seems that's not the case. It would not surprise me at all if the Windows implementations of these two modules are separate.
They are in fact separate. At least by Dan H.'s looking at it. He mentioned that winhttp never actually imports wininet and as far as he can tell, they're separate albeit sharing many similar data structures.
On Friday 18 July 2008 16:11:37 Dan Kegel wrote:
Building winhttp on top of wininet lets us develop on trunk and is probably the fastest path to making a bunch of applications happy, isn't it? That's the way I'm leaning, anyway.
True, but that's been tried already:
http://www.mail-archive.com/wine-devel@winehq.org/msg37935.html
Implementing wininet on top of winhttp looks better architecture-wise. It would solve the problem with retrieving certificates that Zac pointed out and it's cleaner to implement wininet style callbacks on top of winhttp than the other way around.
-Hans
Hans Leidekker hans@meelstraat.net writes in gmane.comp.emulators.wine.devel:
On Friday 18 July 2008 16:11:37 Dan Kegel wrote:
Building winhttp on top of wininet lets us develop on trunk and is probably the fastest path to making a bunch of applications happy, isn't it? That's the way I'm leaning, anyway.
True, but that's been tried already:
http://www.mail-archive.com/wine-devel@winehq.org/msg37935.html
Implementing wininet on top of winhttp looks better architecture-wise. It would solve the problem with retrieving certificates that Zac pointed out and it's cleaner to implement wininet style callbacks on top of winhttp than the other way around.
-Hans
Someone my think why not then implement them as
/-- wininet wine-inet-common -- -- winhttp
ie. move common code to wine-inet-common (or whatever name used) and implement both wininet and winhttp on top of wine-inet-common
/ Kari Hurtta
-
Dan Kegel -
Hans Leidekker -
James Hawkins -
Kari Hurtta -
Zac Brown