[theamk]

Right, I've realized that I asked too many questions in this thread, so I tried to ask more focused question here. You did not answer it, so let me as the most interesting (to me) question:

>> If the answer to the question above is "Arcan will use a different external client for each", then how will those clients be managed? Is there going to be a allow-list of video codecs and text renderers hardcoded into the browser? Or any site can specify any requirement, and browser will just go fetch it automatically on first visit? ...

Since you mention "API breaks", it sounds like list of clients is hardcoded in browser version. So what is the innovation compared to existing web, _from the standpoint of the website author_? I see the the following items:

- Discrete "API Levels" instead of forever backwards compatibility. More bundled libraries.

- Lua instead of Javascript, no WASM or any other low-level/compiled code

- No "HTML equivalent" - if a page wants to do text layout, then it has to pull layout library

- Bundle all libraries in initial package instead of loading them dynamically

- No third-party storage, and maybe first-party is optional too (not sure what's the plat for this.. user prompt? explicit action?)

Did I get this right? did I miss something?

(From what I see, the SHMIF, pledge, Decode/Encode/Network/Terminal, and all this stuff is basically internal browser implementation detail - cool to know if you are a browser author, but does not matter for your typical page writer, right?)

[crazyloglad]

The entire article is from the browser internals angle. The page-writer one comes when we have tools to compile pages into app and layer in user features. The rough path for that is simpler ones first (Sile typesetter and Pandoc), then more exotic ones. An example of the later would be a "print to" modification to a browser that can preserve more content like animations and audio and not be restricted to fixed sized pages.

It is forever backwards compatible. API levels is for the rare few cases where we need to deprecate or break something on the engine side but can apply a runtime fix-up script to replicate the behaviour on the scripting level.

Decode/Encode/Network/Terminal is user-relevant insofar as the set of those are interchangeable binaries. If you want more or less (paranoia, legal environment restrictions) media format support, export or streaming capabilities, etc. those can be swapped out per site without any changes to the engine. What is being considered is to be explicit about expected formats in the manifest so that incompatibilities can be detected.

SHMIF is user relevant insofar as "wasm or low-level compiled code" running as local software can be embedded and controlled by the app, allow-listed by the user.

> No third-party storage, and maybe first-party is optional too (not sure what's the plat for this.. user prompt? explicit action?)

Can you clarify what you mean by this?