Re: [webkit-dev] Regarding WebKit Support Libraries
Hi Jason, We actually changed our network implementation long ago. The one that is in sync with the tree is part of the private support library and we won't be releasing source for it at this time. The one that is in the repository and not in sync is in fact not used, but at one time did work. On 7-Oct-09, at 4:40 PM, Jason Rukman wrote: George, I was wondering if you are intending to push this implementation into the current webkit respository at some point. It looks like the code in your repository is out of sync with the current tree. If anyone else has had success working with wininet on windows we'd like to know so we can also use it to enable file caching and HTTPS support. I haven't seen how we can do file caching with curl. Thanks, Jason. BSquare http://www.bsquare.com Daniel Zucker wrote: Hi Alp and Brent, My vote is to use Wininet. Hi Daniel, You can register your vote by writing and offering to maintain a WinINet http backend. We have already done one. You can find the source for it in our source drop for WinMobile. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
On 17-Feb-08, at 2:27 PM, Alp Toker wrote: Daniel Zucker wrote: Hi Alp and Brent, My vote is to use Wininet. Hi Daniel, You can register your vote by writing and offering to maintain a WinINet http backend. We have already done one. You can find the source for it in our source drop for WinMobile. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
Hi George, Where can I find the source drop? Did you file a bug on http://bugs.webkit.org or someplace? I don't see an obvious place on your torchmobile.com site to grab it. Thanks, -Brent On Feb 23, 2008, at 9:37 AM, George Staikos wrote: On 17-Feb-08, at 2:27 PM, Alp Toker wrote: Daniel Zucker wrote: Hi Alp and Brent, My vote is to use Wininet. Hi Daniel, You can register your vote by writing and offering to maintain a WinINet http backend. We have already done one. You can find the source for it in our source drop for WinMobile. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ 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
Re: [webkit-dev] Regarding WebKit Support Libraries
On 23-Feb-08, at 9:08 PM, Brent Fulgham wrote: I assume the click-through license is for the binary, not the WebKit sources? I.e., the license seems to indicate that I may only make one personal copy of the software, which is not in agreement with the BSD/LGPL license of the WebKit sources, correct? That's correct. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
I assume the click-through license is for the binary, not the WebKit sources? I.e., the license seems to indicate that I may only make one personal copy of the software, which is not in agreement with the BSD/ LGPL license of the WebKit sources, correct? On Feb 23, 2008, at 5:04 PM, George Staikos wrote: http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
Hi Alp, I am happy to contribute to this ongoing effort to make a Windows version of WebKit free from Apple libraries. I would prefer to wait until there is consensus from the community on the best way to move forward, so that my coding effort is not wasted. Cheers, Dan On Feb 17, 2008 11:27 AM, Alp Toker [EMAIL PROTECTED] wrote: Daniel Zucker wrote: Hi Alp and Brent, My vote is to use Wininet. Hi Daniel, You can register your vote by writing and offering to maintain a WinINet http backend. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
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
Re: [webkit-dev] Regarding WebKit Support Libraries
I'd like to see a pretty much pure open source solution available for all platforms. By pure I mean down to the core windowing and libc level. As far as porting curl to WinCE. Found this. http://curl.haxx.se/mail/lib-2002-07/0085.html A obvious reason to have this available is it makes it easier to support new standards or get around show stopper bugs in closed libraries. But generally its a philosophical issue. Outside of designing the port to accommodate multiple solutions it should not have a big impact. In general we already have a problem on the Linux port because of the multiple support libraries possible. Right now this means a number of incompatible versions of webkit need to be installed but 99% of the code is shared. We potentially could have QT/wxWidget/gtk-x11/gtk-directfb/openstep versions on one box. and whatever Adobe is doing. On windows and OSX you add one more. Plus later Googles stuff and whatever Sun is doing. Not to mention applications like mail clients etc. The lack of a shared core makes things troublesome even on the desktop. So the code size argument is a subset of a larger shared code problem with the current project. On Feb 17, 2008 9:15 AM, Daniel Zucker [EMAIL PROTECTED] wrote: 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
Daniel Zucker wrote: Hi Alp and Brent, My vote is to use Wininet. Hi Daniel, You can register your vote by writing and offering to maintain a WinINet http backend. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
Hi there, Another option/alternative to Curl would be POCO - http://pocoproject.org . It has the advantage of being nice C++ cross-platform code, available for all major platforms. Already has nice HTTP(S) and FTP client support. Günter On Feb 17, 2008, at 18:15 , Daniel Zucker wrote: 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Regarding WebKit Support Libraries
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
Re: [webkit-dev] Regarding WebKit Support Libraries
Hi Chris, According to Apple's website (http://www.opensource.apple.com/darwinsource/10.5.2/ ), Core Foundation Lite and CFNetwork are open source under the APSL. However, current versions of these libraries do not seem to actually be accessible (see http://www.opensource.apple.com/darwinsource/tarballs/apsl/ for example). Dr Prabhakar tells me that they are working to resolve this issue, but as yet we have not received word as to when these libraries would become available as APSL sources. Even if the sources were available right now, the current license seems to indicate that users wishing to distribute the software would need to build it themselves. This might be relaxed in the future (as was done for Bonjour), but as of now it seems to be a necessary evil. 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. Thanks, -Brent On Feb 13, 2008, at 7:59 PM, Fuenty, Chris wrote: Hello! I'm reading on two different pages, the first from Apple's developer site (http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html ) stating that there is no distribution of the Support Libraries (which I'm assuming is everything that is bundled within that download. However, I'm reading Alp Toker's blog, regarding the Cairo Win32 Port, and that the non-redistributable CoreGraphics port has been replaced with Cairo, yet keeping the same Network stack and foundation libraries. Taking a guess, are the networking stack and foundation libraries (CFNetwork and CoreFoundation) redistributable? Thanks for clearing this up. c ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
