Should yanic be also a respondd daemon

[genofire]

The https://github.com/ffnord/mesh-announce design of code become more and more unusable.
(e.g. no multidomain support possible - ffnord/mesh-announce@01de2c5)

Maintaince become worse:
Issues not closed or discussed. (PRs are merged without discussion - ffnord/mesh-announce#41)

All this are reasons to make a fork or rewrite
yanic has a lot of need sourcecode /packages already - becouse it collects already thows data

[TobleMiner]

mesh_announce did just get full multidomain support. ffnord/mesh-announce#47 Please test and report your findings.

[genofire]

Nice but my main problem is that my babel support is not merged over years - so I often have to rebase it.

The multidomain support and his unreviewed broken PRs was just a symptom that mesh-announce is not maintained any more.

For me it is/was easier to write some modules here the most logic I have already to parse it.

[TobleMiner]

Well, I'd love to get babel support merged. A primary issue with your support PR is that it does neither have a descripton nor any documentation for the changes applied.
Also I can't test it since I don't have a matching setup. That's why I personally can't do it.
I believe no other maintainer has such a setup either and that's why you PR is not moving forward.

[AiyionPrime]

firstly imo meshannounces major rewrite made it way better.
It's codebase gained a lot of structure, and even if codestyle is still optional, the stability and overview gained through the new configuration made the project fun to use again.

On the other hand, I really like software that does one job, but one job well.
Redistributing collected respondd-data is yanics jobs, spoofing respondd is mesh-announces.

For me it'd be quite a drawback if this became loaded with redundant features.

[belzebub40k]

I really like the feature and we are using it since a while in our community. IMHO it is not a problem if yanic can work as collector and respondd.