First of all, given that the topic is still relates to the Module based runtime interface. I think it should be discussed that that thread. I am not too sure about originality arugment.
In a nutshell though, we should always want to ask whether the features is needed, the additional engineering complexity, and whether it can already be built on top of the existing interface.
I have tried to disucss the rationale on the other related post, trying to do it here again: It is always possible to add new layers of abstractions for new features, but new features are not always better. Adding complexities to the project can bring technical debt, while sometimes they seems to be good in the short term, they could be harmful in the long run.
So the first thing we want to ask, when introducing new features to the core runtime, is to ask “whether it is possible to be implemented on top of existing features”, “whether it is a must have, or a nice feature”, “would they cause engineering burden and extra complexities”, “are we reinvent the wheel that something can be quickly built on top”.
As I may quote: “the best work is achieved not when there is nothing to add, but when there is nothing to take away”.
So to specific to the three proposals.
P0 seems to be a “nice to have” feature, but also will bring quite a lot of problems.
Most developers still uses the suffix to indicate their particular kind of exportation format. We do not want to create yet another “universal model package standard”. There are already a lot of executables executes in all kinds of platforms (e.g. wasm, dylib, so, dll, elf). If we introduce a new kind of universal package on top of these native format, then we will need to be aware of these format in the package.
What is even worse, support a new package format will quite likely involve dlopen, which is not supported in every platform. A better solution to P0, as in the original module runtime proposal, is just make use of the native library format(be it wasm, dylib, so) and their mechanism to load these libraries.
The suffix serves as an important indicator of the intent. Since for the same library, people can choose to cross compile, or package as tar and ship to remote or convert to wasm. Removing the suffix and name is only a seemlying minor change that won’t bring a lot of benefit. If really necessary, users can always built such feature on top of the existing API.
P1 The library exportation will have the option to include packaged parameters. If the user choose not to package the parameters, then we would like users to choose their way of serialization, and save/load param dict already provide the features needed.
P2 library is an accurate name, see the reason explained in P0.
P3 signing can be directly built on top of native platform features, and we don’t have to reinvent the wheel. Just add codesign in the fcompile callback that signs the result executables.
So to summarize, it is not necessary to introduce another layers of abstraction by designing a “universal package format”, doing so will limit our ability to deploy to arbitrary target platforms. Instead, we should just make of the native library format and their capabilities and embed runtime on top of these mechanisms.
It would have been great if the factors, tradeoffs are thought of and discussed in the RFC in the first place to save other developers time during discussion. It is in particular true wrt to the core features of the runtime, where the importance of minimalist have a great weight over the new feature additions. When drafting an RFC, try not only explain “here is a new cool feature”, but also the engineering considerations, whether it can support all the current runtime features effectively, and comparison to alternatives.
