Safari And KHTML May Never Meet
diegocgteleline.es writes "Announcing that Safari passes the Acid2 test has raised some voices in the KDE world. Apple, they say, isn't playing friendly. They don't provide a CVS history, just the modified files where nobody can understand how and when things have changed. It's quite likely that KHTML developers will have to write their own code to pass the acid2 test. Zack Rusin writes: 'All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist.'"
From Rusin's post and links, it looks like the KHTML guys did quite a lot for Apple's sake (creating specific mailing lists and such).
They don't look like they're asking for much, basically they'd like access to the Safari team's changelogs (and internal CVS I think) in order to see how the changes happened, why the modifications were made (because knowing that a modification was done but having no damn clue about why it was done can be quite useless) and where, and which internal of external features the modification uses.
From what i understood, in a nutshell, the KHTML guys merely used to ask for a documentation that was supposed to exist instead of big webcore tarballs, that was more or less denied and the KHTML guys stopped asking for it.
But they're quite annoyed about the buzz over Safari's change getting back to KHTML, which is something that they're not able to do.
On a side note, it should be reminded that KHTML is only part of the K distribution, which means that they can't afford to put more work in KTHML engine alone that on KDE for example.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
He posted the patches because I provoked him to do it. They are the first patches we have received from Apple since late 2003.
Unfortunately they don't merge very well. I've spend a few hours to merge two of them. The rest will probably require redeveloping.
Funny thing is, I think you could argue that the GPL already more or less requires this:
Now it doesn't say that the changes actually have to be documented, but I am reading "the date of any change" to mean that the date for each single change needs to be specified, which would necessitate specifying what change belongs to which date, which comes pretty close to documenting the changes.
To get back on-topic, I'm actually curious if Apple is complying with this rule, and if so, with what interpretation of it. :-p