This is just my personal opinion, but I don’t see why this restructuring should be done on the main repository. Standard practice on GitHub is that if you want to add a new feature to someone else’s project, you fork the repository to your own GitHub, implement the idea, make sure it’s useful, and then submit a pull request.
Quite simply, what I am proposing here is a unified interface to support a production environment-like quality, which can be argued is lacking. If you develop software that is used commercially it is a necessity to structure things to allow an organized higher-level, scalable and reliable system. You have to observe the system as a whole and not just the individual bits you are both dealing with in your pet projects. It does not have this reliability currently because the setup and usage is manual and not automated. It involves lots of tweaking, debugging and dealing with nuances to get a reliably reproducible working product with zero intervention.
It’s like arguing what is the point of an API at all, we should just expose all of the underlying implementations and behaviors to devs. Now what do you think happens when you go to update the core codebase. You have a very tight coupling and dependency nightmare because you didn’t create a structure that allowed loose coupling through the use of higher-level conceptual abstraction. That is the very basis of object-oriented programming.
Don’t get me wrong, I love this library and it provides me a lot of joy to use. But if the demographic commenting here are part-time hobbyists with the perspective of hacking together panels here and there, manually experimenting with commands on a terminal the need will be invisible to them.
My opposition to doing all the work upfront and submitting a final polished PR as I stated in my original post is confirmed by experience here of not receiving traction and avoiding wasted personal time.
I love to debate btw, nothing personal. 
I’m sorry, but that’s life. You have an idea, you spend time implementing it, and then it turns out that few people need it.
I think this discussion has shown that the usefulness of this idea is questionable, so adding it to the main branch would be wrong.
Although, of course, the final say here is up to the library maintainer.
Using a multiple separate scripts like a view as a “higher-level, scalable and reliable system”?? Do you think it is possible?
If you need a complete, efficient, and reliable system, the only way is to write your own higher-level application in C++, C#, or Python… or any other language supported by the API. This way, you’ll get the interface you need, and it will be as reliable and efficient as your developer skills allow.
Assembling a commercial system from individual Bash-driven scripts is a failure from the start.
Nothing personal also :)))))
No that’s incorrect. You plan strategically and collect requirements upfront to avoid performing wasted work, time and effort. Ever heard of Scrum or any software development lifecycle process? You plan, define, design, build, test, deploy and iterate. You don’t implement everything up-front for a client and then serve it to them hoping their expectations are met. That’s a recipe for failure and burnout.
If anything it’s shown a decent back-and-forth between a couple passionate and pedantic devs who care about this codebase, but not what I consider to be a proper evaluation from the community at large. Especially from newer and less knowledgeable users who experience more pains dealing with the codebase and want simple methods to resolve them. There is also a higher chance of entrenchment from more active board-visitors with more rigid views in its usage. In any case I value and respect your opinion. Thank you for your time and patience offering an alternative view. But I have yet to see any substantive commentary offering articulate viewpoints. Just misunderstandings and line-replying to cherry-picked sentences while avoiding substance.
Hmm. Like AWS, cloud computing services or anything DevOps related? Or routers, operating systems, smart/IoT devices or basically every Linux-derived product out there? How do you suppose the backbone of the world’s systems, networks and digital infrastructure runs currently? Perhaps a good majority with an operating-system command language like Bash?
I hope I haven’t crossed the line of politeness in arguing with you.
As for the subject of the dispute, perhaps you’re right, and I don’t understand the gist of your proposals. In any case, it’s better for you to convince the project’s authors, not me.
1 Like
Frankly, the proposed CLI is too broad to integrate and would be a huge maintenance burden.
Recommend creating a separate project to separate concerns.
@deadlift89
To add to yesterday’s discussion, one question.
If you don’t want to develop your proposal as a separate project, or even as a fork with subsequent PR, then how did you even plan to implement it? Develop it directly in the production code?
Thanks. As the holiday near closer I think I am coming around to the idea of wrapping this up and keeping it self-made. As perhaps I underestimated the time maintenance requirements that will be expected of me. But it is a clear trend this is the lens from which most contributors are viewing things instead of utility. Because at the end-of-the-day unpaid time is hard to ask of anybody. I just wish the amount of time I see spent scrolling and answering on the boards were put into improving the actual codebase which confuses me on the time/maintenance argument. I would’ve been happy to receive more representation from newbie users but it’s more likely they only pop-up out of nowhere when they need help on a specific micro-issue of theirs.
Sir, my discussion on this was related to the ultimate destination where this feature will operate once complete. Not just the source control strategy for initial implementations. If the begin-to-end feature pathway is A->B->C I am not fully committing to B before gauging whether C is an accessible end-goal. Because I have seen some good external contributions to this project fizzle out so I am simply exercising caution.
A seperate unknown repo requires time and effort promoting its usage instead of leveraging the network effects of the current install base. And a fork amongst the thousands of other forks is a pathway towards dead code.
Well, yes, I thought that was the norm. Everyone should earn their own points for their project 
1 Like
Withdrawing this feature request due to not enough traction. Thanks for the input everyone.