Hi Alp and Brent, My vote is to use Wininet.
This is because my objective is to eventually support a WinCE version. Wininet is used in both Win32 and WinCE, so it is a convenient choice from this point of view. CURL would be OK if it could be easily ported to WinCE. I haven't looked into that, so I don't know the difficulty. But, I suspect it is non-trivial. Also, it would have the downside of requiring extra code which increases the static application size. (Static application size is an important consideration for mobile use cases). So, I vote for using Wininet. There was Wininet support in the codebase earlier. I believe this could be resurrected without too much trouble. Cheers, Dan On Feb 15, 2008 5:33 AM, Brent Fulgham <[EMAIL PROTECTED]> wrote: > Hi Alp, > > On Feb 14, 2008, at 2:05 AM, Alp Toker wrote: > > > Brent Fulgham wrote: > >> In the medium term, I will probably end up ripping out the > >> CFNetwork code to replace with native windows calls, though it > >> would be nice to avoid this needless work. > > The CURL http backend used by the GTK+ and Wx ports works on > > Windows, though it's not as complete as CFNetwork. It could do the > > job till the CFNetwork issues are resolved. > > In light of Apple's recent notification (today) that CFNetwork would > no longer be available as open source, I think we've got to shift to > the CURL back-end. There are really only three options I see: > > 1. If license allows, take the existing APSL CFNetwork sources and > attempt to use it. Downsides: lots of work to achieve existing > features. No real upside. > 2. Implement native WinInet versions of features from CFNetwork. > Downsides: Single-platform, minimal reuse. Not much assistance to > find problems. > 3. Use CURL library. Benefits: Assist in CURL development, share > code with other project targets (read: I get to bug Alp when I have > problems). Downside: Mostly just the manual effort of > conditionalizing the CFNetwork code. > > Of these, the only one that really seems desirable to me is the CURL > back-end. > > > CFNetwork is integrated into the Win port (consider how HTTP > > resource errors are handled and passed up to the UI) so swapping it > > out for something else may have some unfortunate maintenance > > overhead (ifdefs, more platform splits, and associated build system > > changes). > > Agreed, but I don't see that we have much choice at this point. > > -Brent > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev