Add support for 3D/CAD file formats preview

[kerwin612]

#34775

[wxiaoguang]

I think we need a pure frontend "render plugin" mechanism

1. Register "fronend render plugin"
2. Plugin read page information (for example: file name)
3. If the plugin is able to render it, read the "raw" content, then replace the "fileview" element.

I don't think we should hard-code too many file types in backend.

[wxiaoguang]

IIRC it bloats the binary about 1MB

Can we introduce an config option?

For example:

• RENDER_PLUGIN_ONLINE_3D_VIEWER = https://public-js-cdn/....

[kerwin612]

From a user's perspective, I personally feel that direct integration is better than dynamic loading.
Because building and installation are one-time processes.
However, if we switch to dynamic loading, each time it might require dynamically loading 1MB of JavaScript.
Especially in the current Chinese network environment, sometimes even some external CDNs cannot be accessed, which would directly make the preview unavailable.

So I personally vote for integration.
Of course, the final decision is up to you.

[wxiaoguang]

However, if we switch to dynamic loading, each time it might require dynamically loading 1MB of JavaScript.

Not "each", only once, there is browser cahce.

Especially in the current Chinese network environment, sometimes even some external CDNs cannot be accessed, which would directly make the preview unavailable.

That's why a config option to let users choose, or deploy one locally.

---

If we build the renders into Gitea's binary, then it bloats the binary soon when we introduce more in the future.

[kerwin612]

I fully understand your original intention, but I think this still stems from the perspective of operators. From a user's point of view, such an option shouldn't exist (or there's simply no need for it at all) – the default provided to users should inherently be the optimal solution.

Of course, I recognize that Gitea, as an open-source platform, does have many "operator" users. Your original intention might be to allow them to choose freely, but personally, I wonder if such customization is getting too caught up in minor details?

Alright, I've shared my thoughts. It's up to you all. If adjustments are needed, I'll cooperate with the changes.

[wxiaoguang]

Share some of my thoughts:

There are different requirements for various kinds of files to render.

• Some are widely-used, for example: CSV, PDF, etc
• Some are only used by some of the users: asciidoc, asciicast, console, 3d models, etc. The percentage varies.

So the question is how to make Gitea have a stable and flexible design to satisfy more renders in the future. Then we have some choices:

1. Only make widely-used renders builtin, keep the release binary as small as possible.
2. Make all renders builtin, then we should have some estimation about the side effects, and how large the binary would be in the future.

I haven't got a clear picture of this feature at the moment. What do other maintainers think about?

[TheFox0x7]

on the topic of size I compared 4fc626d with 2e80917 via gsa and this adds 336kB - I don't have a point to make with this, it's just a datapoint for the topic.

---

my 2 cents on the topic are that we might as well bundle this in if it brings benefit to end users. As an user and and operator I'd rather keep dependencies local to my network so in the event my network goes offline (as in I have no connection to external sites) I can use gitea with all it's features without issue.
If we decide to outsource this into a "source the package from there" setting we remove this feature in a way as the only way to have a fully offline instance with all features would be to setup a webserver to host the packages, load them and remember to update them with the instance.

Though I don't mind less common renderers being outsourced to programs which will do a better job at it and it's "easy" to setup. Take pandoc for example - you can take the gitea container, add pandoc to it and you still have a fully featured offline capable gitea (only outside network connection that is required is during pandoc installation).

[lunny]

If we have a render plugin concept, and it can be installed dynamically. It can resolve the bloating binary problem. A render plugin could be a NPM package.

[kerwin612]

Combining the above discussions, I think we need to first reach a unified consensus on the final approach and establish a shared goal before proceeding with the next steps of the work.

[wxiaoguang]

My opinions are:

1. It's fine to make this render builtin
2. Before introducing too many renders and bloating the binary size too much, we need to take at least one action:
   1. Split some sub-commands into a separate binary (especially the git hook related)
   2. Make the renders plug-able