Slashdot Mirror
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.'"
Looking at Safari developer Dave Hyatt's blog it looks like he's provided some patches. I'm sure it will take some work to get those into KHTML, but that seems to be a pretty good start to me.
I give up, no more computers for me.
Love many, trust a few, do harm to none.
In a shocking and unsuspected announcement, Apple will change their name to 'KApple' in an effort to patch relations with other Kommunities.
Have you ever worked on a large project?
Without the revision history, it can be very difficult to track what effect particular changes actually have. Intermediate code cleanups, reorganizations, additional features, etc. can combine to make the code look much different in a fairly short amount of time.
Looking at "what has been changed" makes it much easier to figure out "what does the changed code do".
This might be a good time to remind everyone that the patch has not yet been released to the public. The patch might make the browser unstable - further testing will be required. Depending on how long it takes before the patch makes it into the public version, Safari might not be the first browser to support Acid 2.
From yesterday's summary:
The patched Safari is not yet avaliable for public consumption. It is unknown when the patches will appear in a public version of Safari.
I'll probably be modded down for this...
I don't see how fragmenting KHTML is going to help it much... If people code for Safari, and Safari is the only KHTML based browser that acts lke Safari, the what good does it do for anyone else?
using namespace slashdot;
troll::post();
Every change in khtml has to be run through a regression suite to make sure it doesn't break anything. Now if you fix something a new regression test is added for that.
If you get fixes with no log of what they fix you will end up with bunch of code which you have no idea how to test for regressions. This is just one of the reasons why diffing codebase doesn't cut it.
Another good reason is damned diff is ~6mb because Apple guys never send small patches but only dump WebCore tarballs.
Never learn by your mistakes, if you do you may never dare to try again
There are no trails. There are no trees out here.
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
Now that diff can't tell you why they've changed, but for Pete's sake, you're a developer. You've got the code. You've got the standard. You've got the changes in the code. You've got the old code. You can see how behaviour changes in each. You've (hopefully) got an reasonable general understanding of the codebase.
You obviously didn't read the blog entry.
The problem here is that Apple drops a huge diff on them for every release. It's not individual diffs for each change, but one massive one. We're talking about a diff several megabytes in size consisting of hundreds of changes. With all kinds of changes mixed in with eachother and mixed in with all kinds of Safari-specific stuff.
Yes it is possible to sit and pick that apart. But it's a lot of work. It may very well take more work to seperate out a change than to re-implement it from scratch.
On top of that it's unnecessary work, because there's no reason Apple wouldn't be able to hand over all individual patches seperately, which would make things immensely simpler for the KHTML guys.
Apparently the KTHML guys have tried and tried to get Apple to do this. And they haven't helped.
I can't access kdedevelopers.org, so here's the blog entry:
/. about Safari supporting the all crack Acid2 test and people raving how great it is for KHTML. The truth is that KHTML will probably never get those patches. Whats most probably going to happen is that one of us will simply reimplement it from scratch (and at the moment the reality is that if its not going to be Allan or Germain its not going to happen).
/. or some other equally stupid site will be praising Apple.
You cant even imagine how I hate that question. The truth is most probably never. I just read the article on
Code in Safari is hugely inconsistent and changes are always interdependent. Theres basically no way of merging in one change without bringing a whole bunch of others in. And you know what? Dont even tell me about merging stuff like render_canvasimage.h,cpp. It outright uses OS X apis. Well never be able to merge that in - someone will have to implement it. And whats going to happen when someone does? Some jackass on
In the past when someone spent long hours implementing something in KHTML, they at least got a thank you from people using Konqueror. Now its well finally! It was working in Safari. khtml developers are lazy. Wheres the fun in that?
Do you have any idea how hard it is to be merging between two totally different trees when one of them doesnt have any history? Thats the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDAs with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL.
And you know what? Thats their right. They made a conscious decision about not working with KDE developers. All Im asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. Theres absolutely nothing great about it. In fact it doesnt exist. Maybe for Apple - at the very least for their marketing people. Clear?
Actually the biggest problem right now is that Apple are not keeping up with code-cleanup. We constantly try to develop more elegant easier to maintain code, where as Apple wants the right features - right now.
Safari is basically still KHTML from KDE 3.1 with a ton of bug fixes and features. Many of the features takes time to port because they do not live up to our coding standards.
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.
First of all, anytime you fork off a large project like KHTML the source code bases will start to grow apart. When the new fork has a dedicated group of engineers updating it for their needs then it will quickly diverge to the point where it makes little sense to attempt to keep patches in lock step. In my career I can recall several times where this has happened, and it always seems to come as a surprise to the people maintaining the less active fork.
Apple doesn't use CVS as their normal source control system. To provide CVS documentation, Apple engineers would have to maintain a CVS database as well as maintain their patches in their standard internal SCS. This used to be perforce, I believe, and probably still is as switch a SCS is generally a royal PITA.
Because the sources have been diverging for several years, it's unrealistic to expect that the Safari patches will be directly applicable to KHTML, and I frankly doubt that even having the Safari patch documentation would help very much after several years of Apple patches. This probably isn't anything underhanded on Apple's part. It's just the way engineers work - they change the code to fit their needs, and rarely consider the impact on the old fork that they started from in the absence of an explicit mandate to stay compatible with the old fork. That level of compatibility would require the Apple folks to always have the current KHTML sources and be familiar with that source and particularly to understand the differences between the KHTML code and the Safari code.
Apple does provide the modified files, and usually this is a huge improvement on starting from scratch in implementing a new feature or fixing bugs. It does require the KHTML engineers to be able to read and understand the Safari code. To say that nobody can do that sounds a little strange.
It's quite likely that KHTML developers will have to write their own code to pass the acid2 test.
Well, yes. Should Apple engineers be expected to maintain the KHTML engine also? Apple's engineers are probably focused on their code base exclusively. The KHTML engineers are the right people to modify their own code base. Does anyone expect Apple engineers to be responsible for maintaining compatibility between Safari and KHTML? Apple makes changes, and they provide the changes files to the KHTML team. The rest is up to the KHTML folks if they want to extract the Apple code they want to use and put it into their code.
So Safari is a fork of KHTML then? Fine. Again, I don't want to hear anyone talk about how great Apple is because they give back so much to the open source community. What they do is TAKE from the open source community, fork their code, and give next to nothing back. That is their right. But I don't want to hear anyone praise them for being CONTRIBUTORS to the open source movement, because it is clear they aren't.
Bitch all you want, but Dave Hyatt's changes to WebCore stand a good chance of finding their way back into KHTML
Do you even RTFA? Hell, do you even read the headline? It's written by one of the KHTML Developers.
If you had RTFA, you would have noted that he's not complaning about Apple. He's complaining about you and your uninformed comments. He's asking you, in a more polite way than I will, to shut the fuck up. Because most of Apple's code is completely unusable to KHTML.
1. Use FREE source code from BSD & Darwin.
2. Get lots of FREE BSD & GPL Unix utilities.
3. Use FREE browser source code from KHTML.
4. Beg & plead with MS to continue making Office for Mac.
5. Write the GUI in house and a few other cool apps.
6. Bundle it up and sell it for lots and lots of money and take credit for it all.
Why is everybody missing this KHTML developer's point? It's right there in the short Slashdot summary. He acknowledges that Apple is fulfilling their legal obligations by providing the modified files. But they're not providing any help at all in making their changes useful to the KHTML team. So, there's no "collaboration" at all from Apple's side. That's all. He's not even flaming Apple. If anyone, he's flaming people who misunderstand this situation.
Let's be frank, folks.
- A bunch of developers finds a bunch of bugs and fix it in their source base.
- They hand you their source base, along with loads of information on where the bugs are, and patches that you can't integrate into CVS HEAD.
And the KHTML team is sitting around bitching about the fact that KHTML != WebCore anymore, and how none of the patches can be run against HEAD...
Ok, I was *at* Netscape at the time. I have no doubt that he and his team continue to bust their asses to ship good code, and they're passionate about doing so.
That is not to say that they:
1) Should feel restricted to KHTML's API. That's not in Apple's best interest, and they're not doing this *for the KDE team or organisation*. It's also not fun - they don't run Linux desktops, or KDE, and don't feel like re-entering Netscape's cross-platform hell.
2) Is KHTML nice and segregated? The whole reason WebCore happened was that KHTML was littered with KDE calls. Now the KHTML team is complaining that the WebCore code is littered with Mac API? Imagine my shock. Really.
3) A bunch of people just gave you a ton of information, bug reports, and example code you can *LIFT OUT AND REWRITE*.
Lazy? You're damn right you are. Disillusioned? Yeah, I'll bet. Apple didn't add developers to the KDE project - they added them to Safari. Any idiot can tell *from the starting point* that the only way the browser would happen was to do in WebCore what the KDE team did in KHTML; utterly fail to abstract platform-specifics from the rendering engine.
Personally? I could wish that some big commercial development house would take an open source product I was on, commercialise the development, submit its source code quarterly for me to scavenge for ideas and code where possible, and for it to remain legal to do so.
Is it "ideal"? What's "ideal"? A bunch of other people bend over backwards to make your codebase a nicer place to live in, so they can throw away their deadlines, fix the fact that you didn't separate out the platform dependency in the first place, and burn money on things in the codebase that don't have *any* outward impact except to make it easier for someone else to suck up the code into their tree?
I'll bet you're frustrated. All those damn clouds keep getting in the way of your panoramic view.
It may not be perfect - but it's more than just a little better than nothing; it's actually a hell of a lot of time and effort spent to give back to the community. Even if, in this specific instance, what's given back isn't instantly reusable by that community.
Meanwhile, you can go back to KDE. Not a bad product, but strangely enough, it's hard to run KDE applications without running KDE. It's hard to develop a KDE application that would/could. If anyone has experience with writing applications in an environment that has to cross APIs with fundamental differences in how they perform simple actions, it's the person you're accusing of... of what? Of not being "helpful enough"? Of not being a KHTML team member? Of not being an Apple employee paid to work on a KDE-specific project?
I'm having a really hard time imagining what the fuck is going on in your head, and I'm just not sure it's worth bothering; I suggest you start a rock band and burn off some of that angst on teenagers who are more likely to think that every word that comes out of your mouth is gospel, rather than the drivel it sounds like to those of us of older generations.
-- A mind is a terrible thing.