First off, hnetd was team effort - me, Pierre Pfister and Steven Barth. Secondly, I did not particularly want to promote hnetd but 'existing implementations are bad, boo hoo' argument gets old and I think e.g. https://github.com/jech/shncpd is also quite sufficient. I use even https://github.com/fingon/pysyma 'in production' even now (admittedly not HNCP bits of it, but DNCP + SHSP :->).
On 09.11.2018, at 2.03, Ted Lemon <[email protected]> wrote: > The issue with the code (IIRC) is that it requires cmake to compile, for no > obvious reason, and cmake is hard to get working, so e.g. building it on > MacOS X is a major porting task. And it depends on libraries that I don't > have. And there's no layering of the configuration system aspect of the > architecture—it just goes and bashes on interfaces and stuff (this is my > recollection—I haven't looked at it in a year or so). There's some distinct parts that have well defined interfaces (as far as those 'well defined' go in C anyway) - DNCP (dncp_*), /HNCP code (hncp_*), prefix assignment code (pa_*), and operating system (platform_*) are all pretty loosely coupled. I have compiled the DNCP(/partial HCNP) bits on OS X with relatively minor modifications for my hobby project for example. > These are not bad things that Markus did. Markus was doing what he needed > to do to get it running on OpenWRT. But these are real issues, which are > preventing me from using the code. For someone who is not an HNCP expert to > hack on the code is difficult, and would require substantial work. I could > do it, but I have other things I'm working on. If the code were more > modular, I could experiment with it. This is the problem I was trying to > express. I have used it also unmodified on plain Linux number of times. If you want to use it on something more esotreic, I could bet on OS X port being doable but as lots of HNCP value comes from interfacing with system servers, I do not see anyone writing platform interface for it. I am curious about what 'more modular' code looks like. Separate DLLs? Single function call API between modules? Possibly made out of Lego bricks? Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
