Summary

[Dirk Mueller]

Hi, 

below some random bits I remember, please add or correct parts. its going to 
be huge, but please take a minute to skim through it, thanks. 

- Common codebase: My impression was that we're not going to work on this
  goal before Safari 1.0 (or even Safari 1.0.1 / 1.1). This is what
  we feared but expected. Many things have to be sorted out, like extracting
  bits in _darwin.cpp and _x11.cpp files that are plain unportable. 
  (The biggest change seems to be the misc/decoder and rendering/font to
  me, everything else should disappear in the near or middle future anyway). 

  re: rendering/font.cpp: its clear that we never reach a common codebase
  here. I'll just rename our file to font_x11.cpp soon in CVS, Safari
  can just fork the complete file and name it font_darwin.cpp or whatever.

  re: misc/decoder.cpp: Our code is crap basically, as we don't do
  automatic encoding guessing properly and are by far wrong in many cases. 

  Question: How does Safari handle this? It seems the encoding conversion
  is done on a different layer, as you made decoder basically a noop wrapper
  as far as I can see? How are you guessing the encoding? Any code we can
  share here, or is it OS / proprietary code base level?
  
  Plan was to do patch-wars till we have time to sit together and figure
  out the political details of a common CVS repository etc. 

  It was suggested to sync up safari codebase with the latest stable 
  release, which is KDE 3.1 (3.1.1 soon). Should Konqueror backport the
  new CSS parser for 3.1.1 ? Its definitely still hardly tested. Also
  I'm personally unsure about the performance impact of the new CSS parser,
  I've heard that bison generated code is quite slow (gcc developers
  are bitching about that). IMHO it requires profiling first. 

  It was suggested to meet in person when the Safari team has less time
  pressure and sit together to finally establish a common codebase. My
  impression was that both sides agreed that this is a good idea. 

- Testsuite: The "No regression" topic was discussed, and both sides
  expressed interest in achieving an automated regression testing before
  commit. Safari codebase apparently has automated testing already for
  rendering quality, stability, memory impact and performance (Mozilla
  development style comes to my mind..). 

  The common testsuite bit was hairy. Safari uses testsuites that are not
  public and not shareable under any open source compatible license. 

  However IIRC it was suggested that we receive a tarball of tests
  that Apple can share with us. It was recommended to set those tests
  up in the KDE CVS module khtmltests. Probably a more automated regression
  testsuite is needed here. We should discuss here how to make sure
  we don't introduce regressions for each others code bases.

  It wasn't noted IIRC is that we maybe should try to aim at a common
  testsuite with Mozilla as well in the (far) future. 

- Commit policy: Safari's internal policy is at least one review of the
  patch before commit. The commit has to include a changelog entry and
  a testsuite testcase. 

  KDE's policy is.. lets say currently less than that ;-)

  Safari developer will get access to KDE CVS, to commit changes directly. 
  IIRC it was accepted that bigger changes are discussed at least
  briefly before commit. 

  The topic of disagreement over the further direction of KHTML/KJS
  development was brought up. We didn't see it as a problem so far. 

  Hopefully cooperation, coordination  and early exchange of ideas and 
  patches will avoid that. 
  
- User agent string: Safari developers explained their choice for 
  a Mozilla like UA string. No consensus on that topic AFAIK, and
  as we need UA spoofing for a lot of braindead real world websites
  anyway there is not much to decide. I'll write a separate mail
  about some of my ideas about this topic. 

- Common user agent string: It was accepted to share a common
  part in the user agent string to allow sites that want to 
  create a khtml-specific version of their webpage to recognize
  Safari and Konqueror to be the same browser, essentially. 

  This way linux-centric sites (which do optimize for Konqueror
  sometimes) and mac-centric sites (which will obviously optimize
  for Safari) can still be equally browsed with both browsers. 

  In an ideal world we could share a String with Mozilla 
  (to be recognizeable as "DOM-browser") though..

  Maybe we have the power to establish a better browser detection
  sheme now, in the hope that at least some web designers use
  the "right" code. Both sides have probably already experienced
  the frustration about web sites that simply send the wrong
  page to the browser just because it is not named MSIE or Netscape. 
  Ok, I'm dreaming here..

- Patch wars: It was suggested to put up the source code of the
  weekly internal Safari releases for us to peek at, to be able
  to track changes in smaller steps. 

  It was also suggested to share "change-sets", so that we can
  easily apply changes to both trees. Safari developers explained
  that they cannot share their CVS / CVS commit logs with us, as
  it may contain references to proprietary code or internal issue
  tracking systems or otherwise contain stuff that could cause legal
  trouble for Apple/Safari. 

  However, we might be able to manually or semi-automatically post
  "change-set" diffs to this mailing list to make merging easier. It
  was recommended that both sides look into this and work something out.

- CVS logs: Konqueror developers suggested to CC all khtml/kjs related
  commit logs from the mailing list kde-cvs to khtml-devel for easier
  tracking / merging automatically. It was explained that the Safari
  developers don't need this, as they read kde-cvs anyway. 


<fill in the rest>


-- 
Dirk (received 578 mails today)