4 ms·

So I think they are defining whether a given API as "open" or not as whether it is callable from JavaScript? So they're only willing to edit the JavaScript cod

by evmar 7y ago

So I think they are defining whether a given API as "open" or not as whether it is callable from JavaScript? So they're only willing to edit the JavaScript code, but not the C++ code alongside it? (I am genuinely confused by the reasoning, questions are not rhetorical.)

jamoes 7y ago
My interpretation is they're saying that Chromium's address bar code is complex deeply integrated with many other parts of the code-base (including many parts that interact with Google's search APIs). On the other hand, Firefox's address bar code exposes a simple javascript API. This means that making and maintaining custom modifications to the address bar is easier with Firefox.
- bagacrap 7y ago
  Ever since Chrome Beta users have been able to change the search engine that powers the omnibox (to include autocomplete suggestions, not just search results).
  - xemdetia 7y ago
    Changing the search engine that powers the omnibox is different than changing the behaviour of the omnibox, which is kind of a lot when it comes to predictive search, predictive completion and a bucket of other things that I wish you could turn off (or can be turned off for a while before Google decides you shouldn't ever need or want to turn it off). It's a target with a huge amount of churn. I agree that Firefox is a more sane target as a developer.
    - bagacrap 7y ago
      The gp's parenthetical addresses what you call "predictive completion", only it uses the term "autocomplete".
      - Dylan16807 7y ago
        It addresses changing the site that feeds it. It does not address changing the behavior.
rishav_sharan 7y ago
I think, Open as in scriptable and documented. Chrome has many undocumented apis and most of it is in c++. Not everything is exposed to the webview area.
hackinthebochs 7y ago
An open API implies a certain intent of the author. If there is an open API to utilize some feature, that implies an expectation that others will use it and thus an expectation of a consistent interface version to version. If you're forced to go around monkey-patching the core framework, you can expect a moving target as there is no expectation of external users thus no motivation to maintain a consistent interface between versions. So in this case, the core framework being exposed to javascript is evidence of the expectation of external users, thus it will likely not be a moving target. If you're modifying some software, you will greatly prefer programming to an API than not.
pdpi 7y ago
When you decide to fork a project, a key concern is: how invasive are your changes going to be? This is a very large component of how easy or hard it will be to merge upstream changes in the future. In this case, going with Chrome would mean very invade changes to enable exposing things the upstream specifically wants to keep private in their codebase. Firefox instead requires only well-delineated, minimally invasive changes because there is a nice clean boundary between UI code and engine code (which incidentally matches c++/js boundary, the languages themselves don’t matter much), which means their changes can be isolated to the UI layer, which in turn means a much cleaner path to merging upstream changes
MiroF 7y ago
This reasoning makes sense to me. If you have a JS api, to me that implies a consistent and maintained interface. Modifying the internals seems like it could easily become deprecated or have to be completely different with a single wrong PR

by evmar 7y ago

jamoes 7y ago

My interpretation is they're saying that Chromium's address bar code is complex deeply integrated with many other parts of the code-base (including many parts that interact with Google's search APIs). On the other hand, Firefox's address bar code exposes a simple javascript API. This means that making and maintaining custom modifications to the address bar is easier with Firefox.

bagacrap 7y ago
Ever since Chrome Beta users have been able to change the search engine that powers the omnibox (to include autocomplete suggestions, not just search results).
- xemdetia 7y ago
  Changing the search engine that powers the omnibox is different than changing the behaviour of the omnibox, which is kind of a lot when it comes to predictive search, predictive completion and a bucket of other things that I wish you could turn off (or can be turned off for a while before Google decides you shouldn't ever need or want to turn it off). It's a target with a huge amount of churn. I agree that Firefox is a more sane target as a developer.
  - bagacrap 7y ago
    The gp's parenthetical addresses what you call "predictive completion", only it uses the term "autocomplete".
    - Dylan16807 7y ago
      It addresses changing the site that feeds it. It does not address changing the behavior.

rishav_sharan 7y ago

I think, Open as in scriptable and documented. Chrome has many undocumented apis and most of it is in c++. Not everything is exposed to the webview area.

hackinthebochs 7y ago

An open API implies a certain intent of the author. If there is an open API to utilize some feature, that implies an expectation that others will use it and thus an expectation of a consistent interface version to version. If you're forced to go around monkey-patching the core framework, you can expect a moving target as there is no expectation of external users thus no motivation to maintain a consistent interface between versions. So in this case, the core framework being exposed to javascript is evidence of the expectation of external users, thus it will likely not be a moving target. If you're modifying some software, you will greatly prefer programming to an API than not.

pdpi 7y ago

When you decide to fork a project, a key concern is: how invasive are your changes going to be? This is a very large component of how easy or hard it will be to merge upstream changes in the future. In this case, going with Chrome would mean very invade changes to enable exposing things the upstream specifically wants to keep private in their codebase. Firefox instead requires only well-delineated, minimally invasive changes because there is a nice clean boundary between UI code and engine code (which incidentally matches c++/js boundary, the languages themselves don’t matter much), which means their changes can be isolated to the UI layer, which in turn means a much cleaner path to merging upstream changes

MiroF 7y ago

This reasoning makes sense to me. If you have a JS api, to me that implies a consistent and maintained interface. Modifying the internals seems like it could easily become deprecated or have to be completely different with a single wrong PR