[webkit-dev] Regarding WebKit Support Libraries

[Mike Emmel]

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 <zucker at wake3.com> 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 <bfulgham at gmail.com> 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 at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>