Hello, Just some further notes about webkit to prevent further similar bugs about other webkit ports.
Apple forked KHTML & KJS, improved it and make Safari browser because deal with Microsoft for Internet Explorer was running out. Obviously they had to opensource and they called the forks WebCore and JSCore respectivly and Safari browser was sitting ontop of that with backend call WebKit. Later they moved WebKit out of Safari closer and combined WebCore with JSCore into just Webkit. Safari then became lighter and could do more changes to gui. But WebKit was still tangled up with Objective-C & MacOS frameworks. Apple needed good engine for iTunes & iPhone. At this point they dissabled Webkit into it's somewhat current layout to make it easy to build different types of libraries around it. This allowed them to do 3 ports the Webkit MacOs framework as used by safari, the Windows C++ framework for iTunes/Safari. Then later they reused that codebase to create Webkit for Cocoa Touch on iPhone. From blackbox testing you can interspect that those ports (as reffered upstream) are quite good stable/api libraries but they are very different beasts which even Apple cannot use interchangeably across their products. But it's very great content engine which lets you relatively easy to make a library out of it for the purposes you need. Then nokia did the S60 port, stated the QtWebkit and then Google did 3 more ports for the V8/Chromium. All of them are very, very different beasts with completely different dependencies, libraries and goals. And then somewhere there started the gtk port. >From support & security point of view they will have mostly different bugs & patches and in deed all have separate security maintainers. >From experience windows safari gets more cve then mac one excluding platform specific ones, because they are very different pieces of software. So in the future if it will be packaged we will currently have GtkWebkit, QtWebkit and V8/Cromium Webkit, possibly Maemo/S60 Webkits as well. Which as far as I can see will be build out of different branches from respective publishers. They are converging at different levels for test-suites and core functionalities but ports still use very different sets of dependencies and provide various degrees of API/functionalities. "WebKit is not a bundle of maximally general and reusable code." "WebKit is not the solution to every problem." [1] You really need to do a separate port / fork of it to make a library for your needs. And as for releases it's waterfall / rolling model with webkit constantly targetting latest HTML / SVG / and other standards with ports ship under their schedules. This is very general overview and I might be wrong on a few things but webkit is not a stable library with bindings it's more like LLVM which you can use to build something you need. [1] http://webkit.org/projects/goals.html -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
