On Sun, Jul 26, 2020 at 12:34:00PM +1000, Matthew P. Grosvenor wrote: > This is exactly what I’m trying to avoid: committing the cardinal > sin of open source. If the project doesn’t do exactly what you need, > just write yet-another similar but different implementation written > in yet-another language, rather than maintain and extend the > existing one.
I don't see any difficulty here. After all, the management interface is an API that is more or less set in stone. There is no danger of multiple forks here. One of my personal principles for this project is to avoid gratuitous library dependencies. The code only depends on Linux kernel v3+ and GNU libc, and that is a GOOD thing. Long experience in systems level programming and embedded systems taught me through how costly dragging in libraries can be. You will notice that, rather than using libconfig, for example, I opted to write my own simple configuration parser. I don't reject library dependencies categorically, but there has got to be a very strong justification before I will let additional dependencies in. I don't feel that having json output, for example, is a compelling reason. The scope of this project is to provide a user space Precision Time Protocol stack. The pmc program is only meant as an example and as a way to test the management interface. A fully featured client is out of scope. A proper design would require lots of extra dependencies, like database, gui, scripting, reporting, alarms, network management, and so on. I would be supportive of an open source project to develop a fully featured PTP management client. Heck, I might even contribute now and again, but I myself cannot take the lead on such an endeavor. Because of the strong binary API, there is no downside to having such a client as a separate project. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
