chromex updates broken?

[grzm]

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

https://github.com/binaryage/chromex/commit/022c2a16a0be6f1e64395c29d44a4c6f0495f04c

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]

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]

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]

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]

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

[noitcudni]

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

[noitcudni]

@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]

This is my latest apis.json: https://www.dropbox.com/sh/bkatyx0f21w8ioo/AABHxoL0pu_UUdxMVRZiadXUa?dl=0 @noitcudni ^^^