On Mon, Jul 08, 2024 at 09:59:20AM +1000, Kevin Koster wrote:
>That would be great. Provided it doesn't actually end up as complicated
>as iptables configuration of course. :)
Yeah, I'll have to think how to avoid that too :-)
I'm putting my thoughts into an RFC here:
https://github.com/dillo-browser/rfc/blob/rfc-002/rfc-002-rule-based-content-manipulation.md
(On Dillo it renders ok without remote CSS)
Let's see if I can keep it simple.
Rodrigo.
I think a good way is to reduce functionality to a minimum. Not to make a full scripting language, but rather moderately complex hook rules that can call external scripts or DPIs with complex functionality.
Another mistake that can be made is to replace the DPI infrastructure. I think a cooperation between the two is better.
DPIs and authorized scripts can set temporary rules and be called by dillo on events.
Fixed rules in a rules file call complex scripts or DPIs.
The problem with the DPI infrastructure is that it is an unfinished infrastructure with very little documentation.
For example: uncontrolled mime types can be implemented by sending a DPI command to the DPI service "mime.<mime_type_name>" and using the same functions as vsource. To handle, for example, text/markdow or image/webp, put mime.text/markdown=... and mime.imge/webp=... in dpidrc.
I think this is the only way to have a lightweight device with more functionality loaded only when used.
(Sorry for my English. My native language is Spanish)