MineOS being built on Node.js

I have started development on a new MineOS server using node.js technology. For those of you unfamiliar with node.js (as I was a week ago and still am), Node.js is a platform that will serve as the back-end for the web-ui and will offer many new benefits over the current Cherrypy-based server.

  • event-based model, which should increase the web-ui’s ability to be responsive and real-time.
  • lightweight and highly scalable.
  • being based on Javascript might appeal to a wider audience of contributors
  • it’s something new for me to learn

If you are interested in following in the development, check out its git page. I welcome any PRs or discussion about where this node.js based server may go.

If anybody has any recommendations, feature requests, or ideas, please don’t hesitate to let me know!

This is great news! Each version a gets better and better. I hope to see log parsing. Although if you provide the framework for parsing and allow the user to create the format and rules it would save everybody work and headache. when I have some time I’ll try to lay out my reasons for why this would be the best approach and an idea of how the framework might look that you could provide.when I get a chunk of time I have a pool of time dedicate a thread to it.

After almost 4 years of MineOS, I’m convinced users want everything done for them, rather than have frameworks and flexibility. There might be a few admins here or there that will know how to regex and find the logs they are looking for, but the vast majority (surely, more than 95%) of users are likely to ignore anything that requires that level of involvement.

One example is profiles, where I tried to build profiles in such a way that is extensible to any kind of server software out there–but yet, I get constant requests to include all varieties of FTB, DW, etc to stock_profiles. I won’t preclude the possibility that the profiles model is somewhat irregular and hard to understand, but it’s as straightforward as I know how to make 5 input boxes–if I cannot manage to make that highly-intuitive to the masses, I likely don’t have the UI skill to make a log-parsing framework intuitive for the same audience.

That said, I still wish for the web-ui to never compromise flexibility where I can avoid it, so I’d like to hear your reasons and details of your approach, which is certain to produce a better product than simply relying on my own insights exclusively.