8 Oct
2018
8 Oct
'18
10:10 a.m.
For example, we had this problem (missing an option). In fact me and
another guy after resolution we felt that this was not for us, that we
wanted to work directly with config files from openwrt
https://github.com/libremesh/lime-packages/issues/339
Libremesh does zero effort reading openwrt configuration (but
really, I see no effort to have this features. Is like, I have enough
with one universe, I don't need to think in parallel universes). Lime
proposed "solution" is to use lime config. But using lime config
implies having to do consensus (and touching strange parts of code I
don't get) on what options are used for the community / in general.
But in the end, we are designing "good configuration files" for
devices compatible for our routing protocols. At the moment what I
think is: this is too much complexity. I know openwrt works the same
way with code written in C. Templates architectures, devices, etc.
Libremesh does the same but with lua code? I have enough with openwrt
complexity. And most importantly, I want users interact sharing their
config files. So I prefer a blind approach: "this options works,
include it, or I include myself".
You are saying that is not justifiable because libremesh does the
same. I did an effort to understand libremesh, did you try to
understand temba? I don't have so much documentation but essentially:
erb templates on config files per device (some files are shared)
evaluated from inherited yaml files with two interfaces: rake and
rubyonrails form.
Do you understand now how different are the firmwares and that they
are trying to solve the problem with very different approach?