Proposal: libcuberite
#1
Hi folks!

Last week I stumbled upon the idea to split up cuberite into several parts:

  1. libcuberite        -> the core library with all the backend functionality
  2. cuberite-cli       -> the command line interface
  3. cuberited         -> the cuberite deamon
  4. ( cuberite-qt )  -> the cuberite qt frontend
  5. ( cuberite-gtk ) -> the cuberite gtk frontend
  6. cuberite-jni       -> Android wrapper
For clarification, this would dramatically increase the flexibility of the source-code. We would be able to let anyone implement an interface to the server backend. Even a web-frontend would be possible.

So what do you think?
Reply
Thanks given by: yangm97
#2
I really like the idea. Should we also allow hooks for programs that interface with libcuberite though? That way it should be easy for programs to know if a player joined or left or if something else happened. Is it even possible to do this properly? We're hesitant to implement C++ plugins because it's not easily done for multi-platform. If we don't do something like this all you can pretty much do is start and stop a server.
Reply
Thanks given by: sphinxc0re
#3
What I'm trying to do is putting together a todo list for the libcuberite migration. But I really don't know what is needed for that.
Reply
Thanks given by:
#4
Some form of "hooks" would be beneficial and in fact even necessary. If the server is to be restarted using webadmin, libcuberite needs to notify the wrapper app about that; console output will be provided as a callback. So whatever API we implement for use between libcuberite and the wrapper app is up to us.

Note that this would benefit from de-singleton-izing the entire server (so that multiple cRoot instances are allowed) - the wrapper can then create a cRoot instance, initialize it with whatever settings and callbacks it wants and then run it. Not sure how to handle logging, though.
Reply
Thanks given by:
#5
Now that I almost finished android app....... Although I don't like the jni for running cuberite on android (for the reasons, see our long discussions on github) separating the cli and a library seems good, although I don't know whether the benefits are greater than the drawbacks (especially for installing updates frequently it wouldn't be good to tighten cuberite with the respective app, bug reports would suffer too (you can handle a webinterface with ease by just running separate processes and you would have consistent code base and therefore the same bugreports. It's just easier than strange bugs appearing only on one platform). And a web app would be the next thing I would do after android.)
Reply
Thanks given by:
#6
Hi - I just joined hoping to find some discussion about setting up Cuberite as a C++ library.

With such a library, would it be possible to integrate cuberite into another language?
I ask because I've developed a Common Lisp compiler that interoperates with C++ and I've always dreamed of tying it into Minecraft somehow.   I'd like to teach my daughter to program and a Common Lisp repl that controls a Minecraft world and generates code that runs almost as fast as the C++ code that it is interoperating with was something that I've always wanted.

Interpreted Lua is fine for scripting but it is not going to be fast enough for the stuff I want to do and teaching C++ is... well - you know.
Reply
Thanks given by:
#7
Sounds like a good project. I guess it is totally possible to write bindings for any other language.
Reply
Thanks given by:
#8
Although possible, it would be an enormous amount of work to actually do that, and even more work to maintain.
Reply
Thanks given by:
#9
Looks promising. If I understand well, having libcuberite decoupled from cuberite daemon would allow things like having a separate chunk server to be implemented easily?
Reply
Thanks given by:
#10
No, not that likely. Things are still too much coupled, and the UI / backend decoupling that we're discussing here is not nearly enough for a chunk server.
Reply
Thanks given by: yangm97




Users browsing this thread: 8 Guest(s)