Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chromex updates broken? #25

Open
grzm opened this issue Mar 5, 2022 · 7 comments
Open

chromex updates broken? #25

grzm opened this issue Mar 5, 2022 · 7 comments

Comments

@grzm
Copy link

grzm commented Mar 5, 2022

It looks like the nightly branch of Chromex hasn't updated since April 6, 2021.

022c2a1

This update is based on a Chromium commit from December 26, 2020 (https://chromium.googlesource.com/chromium/src.git/+/3fc45039a8ff08a79015c72d3daf0435523ae278)

I suspect the issue may be due to the removal of the docs server code from the Chromium repo on December 29, 220. (https://chromium.googlesource.com/chromium/src/+/683a77f65e106bb06d42bab253e6c31efd16aebc)

I'm very new to both Chromex and Chromium, so there's a great likelihood that I'm misunderstanding what's going on. Is there a more up-to-date version of Chromex available? Has Chromium moved on enough that a new version of Chromex is warranted?

@darwin
Copy link
Member

darwin commented Mar 5, 2022

I confirm.

Chromium devs removed the old docs server and I didn't have time/motivation to port chromex api-gen scripts to their new system. I created chromex for the dirac project which is discontinued. And I don't have any other use case for chromex right now. I was hoping to update chromex at some point but never got back to it.

Any volunteers? :-)

Maybe we should at least put some disclaimer into chromex readme at this point.

@grzm
Copy link
Author

grzm commented Mar 9, 2022

Thanks for confirming! I've been rummaging around looking for how the docs are being generated now in hopes that it might not be too hard to adapt the process you have for the old doc server code. It looks like the api reference data is fetched from a Google Cloud bucket:

https://github.com/GoogleChrome/developer.chrome.com/blob/main/external/sync-external.js#L16

The chrome-types.json object in the "external-dcc-data" bucket has contents that looks like (edn-ified):

{:chrome_url_overrides
 {:children [],
  :sources [{:fileName "", :line 7134, :character 19}],
  :name "chrome_url_overrides",
  :kindString "Namespace",
  :_type
  {:properties
   [{:children [],
     :_pageId "type-UrlOverrideInfo",
     :sources [{:fileName "", :line 7136, :character 21}],
     :name "UrlOverrideInfo",
     :kindString "Interface",
     :_type
     {:properties
      [{:_pageId "property-UrlOverrideInfo-bookmarks",
        :sources [{:fileName "", :line 7146, :character 6}],
        :name "bookmarks",
        :kindString "Property",
        :type {:type "intrinsic", :name "string"},
        :_feature {:channel "stable"},
        :id 2267,
        :kind 1024,
        :comment
        {:shortText "Override for the chrome://bookmarks page."},
        :_name
        "chrome.chrome_url_overrides.UrlOverrideInfo.bookmarks",
        :_pageHref "chrome_url_overrides",
        :flags {:isExternal true, :isOptional true},
        :_comment "Override for the chrome://bookmarks page."}
        ;;; ...

Does this look like something that can be munged to generate the Chromex lib? I understand Chromex isn't something you may be interested in maintaining any longer, but if it's not too deep of a rabbit hole, it might be an itch I'm willing to scratch.

@darwin
Copy link
Member

darwin commented Mar 9, 2022

Thanks for the investigation. I just looked at chrome-types.json in the bucket and it looks like it contains all info needed for chromex.

Two approaches come to my mind:

  1. to rewrite api-distiller to take chrome-types.json as input and transform it into old server data format so that api-gen can work with it (sounds easier and would ensure compatibility with previous chromex versions)
  2. to rewrite the whole tool chain including api-gen to take chrome-types.json and generate chromex files based on this new format (future proof but higher chance of breaking changes)

Please note that chromex is heavily based on macros which generate stub code from generated api tables. For a non-trivial example look into the tabs namespace. We probably want to keep this data format so we don't have to rewrite those macros.

I think it is doable. Also please note that beta Chrome APIs are planning to offer promise-based APIs. Maybe we should wait for them and also update chromex to expose them somehow or maybe use them instead of callbacks. Not sure if this could be done transparently for current chromex library users.

Also I'm open to fork this into chromex2 effort and drop backward compatibility at that point.

@noitcudni
Copy link

@darwin Do you have a json file with the old server data format lying around?

@noitcudni
Copy link

Also, unless I missed something, I think promise-base APIs are supported already. Here is an example.

@noitcudni
Copy link

@darwin Do you have a json file with the old server data format lying around?

Ah, I think I can just check out an older version of Chromium and run the build-cache.sh script.

@darwin
Copy link
Member

darwin commented Jun 11, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants