7 ms·

I don't see what is noteworthy about this. It's not a new site so why the interest?

by cbf 15y ago

jws 15y ago
I think perhaps because the WebCore for iOS 4.3.3 is in there. There was a "squeaky wheel" episode a week or so ago about Apple not releasing all of the source code for LGPL projects in a timely manner, this may be the "grease".
- saurik 15y ago
  Apple still has not released the requisite source code for WebCore (they redact code from it for their WAK* classes that they are not allowed to by the license, and which stymies work on iOS WebCore modifications).
  - tzs 15y ago
    Who wrote the WAK* classes?
    - saurik 15y ago
      Given that these classes have been maintained at Apple over the course of multiple years, I'd imagine multiple engineers were involved in it's construction. If your intention is to track them down personally and harrass thrm, I'd rather this be taken up as a matter of corporate policy ;P. (Seriously, though: why does this matter?)
      - tzs 15y ago
        If they were written by Apple employees, then Apple likely owns the copyright on them, and the claim that Apple is required by some license to release their source is then in doubt.
        saurik 15y ago
        I'm sorry, are you serious? Apple chose, of their own volition, to modify, compile, and then distribute a derivative version of WebCore, a project clearly licensed under the LGPL. In order to be compliant with this license, all new/modified code statically linked to the code they took must be cleanly separated from the rest of the binary in a fashion that would allow a working replacement to be compiled and used in its place. So, whether they want to cough up the code for WAK* or "just" give us un-linked clean object files so I can link their work together myself, as it stands they are simply violating this license, and the only thing "in doubt" is their right to use and modify WebCore.
        jws 15y ago
        Out of curiosity… Why would someone use a locally modified WebCore in iOS?
        saurik 15y ago
        Normally, developers are able to get away with monkey-patching the compiled code in memory; but, in some cases, you simply need drastically different settings. A while back (important, as Apple now added this feature... at least I think) some developers managed to sort-of-almost recompile WebCore (with some horribly reverse engineered hack for the redacted parts) in order to add RTL (right-to-left text rendering) support: their goal was to get Hebrew better supported (a goal that was mostly successful, and was used by a large number of people in Israel, with nearly everyone in Israel using it). Even when you take the monkey-patching route I generally prefer (as it allows you to more easily stack patches from multiple developers/vendors), modifications to a C++ library like WebCore are much much harder if you don't have the original source code. In my case, I add a new <script language=""> handler for "text/cycript", a dialect of JavaScript that allows inline Objective-C syntax (similar to Objective-J) that bridges to native code, so it can be used by people developing HTML desktop widgets.

I don't see what is noteworthy about this. It's not a new site so why the interest?

by cbf 15y ago

I don't see what is noteworthy about this. It's not a new site so why the interest?

jws 15y ago

I think perhaps because the WebCore for iOS 4.3.3 is in there. There was a "squeaky wheel" episode a week or so ago about Apple not releasing all of the source code for LGPL projects in a timely manner, this may be the "grease".

saurik 15y ago
Apple still has not released the requisite source code for WebCore (they redact code from it for their WAK* classes that they are not allowed to by the license, and which stymies work on iOS WebCore modifications).
- tzs 15y ago
  Who wrote the WAK* classes?
  - saurik 15y ago
    Given that these classes have been maintained at Apple over the course of multiple years, I'd imagine multiple engineers were involved in it's construction. If your intention is to track them down personally and harrass thrm, I'd rather this be taken up as a matter of corporate policy ;P. (Seriously, though: why does this matter?)
    - tzs 15y ago
      If they were written by Apple employees, then Apple likely owns the copyright on them, and the claim that Apple is required by some license to release their source is then in doubt.
      - saurik 15y ago
        I'm sorry, are you serious? Apple chose, of their own volition, to modify, compile, and then distribute a derivative version of WebCore, a project clearly licensed under the LGPL. In order to be compliant with this license, all new/modified code statically linked to the code they took must be cleanly separated from the rest of the binary in a fashion that would allow a working replacement to be compiled and used in its place. So, whether they want to cough up the code for WAK* or "just" give us un-linked clean object files so I can link their work together myself, as it stands they are simply violating this license, and the only thing "in doubt" is their right to use and modify WebCore.
        jws 15y ago
        Out of curiosity… Why would someone use a locally modified WebCore in iOS?
        saurik 15y ago
        Normally, developers are able to get away with monkey-patching the compiled code in memory; but, in some cases, you simply need drastically different settings. A while back (important, as Apple now added this feature... at least I think) some developers managed to sort-of-almost recompile WebCore (with some horribly reverse engineered hack for the redacted parts) in order to add RTL (right-to-left text rendering) support: their goal was to get Hebrew better supported (a goal that was mostly successful, and was used by a large number of people in Israel, with nearly everyone in Israel using it). Even when you take the monkey-patching route I generally prefer (as it allows you to more easily stack patches from multiple developers/vendors), modifications to a C++ library like WebCore are much much harder if you don't have the original source code. In my case, I add a new <script language=""> handler for "text/cycript", a dialect of JavaScript that allows inline Objective-C syntax (similar to Objective-J) that bridges to native code, so it can be used by people developing HTML desktop widgets.