Implementation Discussion Thread: CLI

[Gaelan]

Here's a thread to discuss the implementation of the CLI, which will be a command-line wrapper around the client core. It will be the main UI for this until the GUI is implemented. Questions we need answered before we can start work on this:

• What technologies will be used to implement this?
• Can these technologies work with a small memory footprint?
• How hard is it to port a tool written with these technologies across OS X, Linux, and Windows?
• Are these technologies compatible with the interface provided by the Client Core?
• Who will work on this?

[MaPePeR]

Small memory footprint, easy to port and good on CLI? The only thing I can think of is C, because it does not come with an interpreter like Python/Java or a giant executable like Go.

[Gaelan]

Yeah, a systems language (C family, Rust) seems like probably the best option. Note that this decision is related to #2, as the CLI will need to talk to that library. Also, we will eventually want a GUI, so our technology decision should factor in support for GUI frameworks as well. We certainly can't go wrong with C, though Rust might be easier to work with. Downside: newer.

[rchard2scout]

The CLI should probably be a simple wrapper for the library (the same way most *nix commands have an equivalent system call). That means it'd probably be easiest to write it in the same language as the core. If we're using a C family language, portability will be harder. We could use Java (or another language that compiles to JVM bytecode, like Scala), which will be easier for portability, but slower.

[MaPePeR]

Besides shipping multiple binaries I don't see much problems with portability when writing in C.

At least not when writing a CLI. (except for some simple rules when dealing with file paths)

[rchard2scout]

For the CLI, maybe not that much. For the core library, it'll be a bit harder, because that'll have to deal with stuff like networking and multithreading. I've used a Microsoft API in the past, and it's quite complicated (granted, that was DirectX 9, but I can't image the Win32 API being much easier). We could write the core in Java and use the JNI (which I just learned about existed, and which sounds interesting), but that might be overcomplicating things.

[Gaelan]

I think the client should not be written in Java, unless we can get it to run with less than a few hundred megabytes (I have found that often I want to close the launcher when running a big pack on my 4GB laptop to save memory). C, C++ and Rust seem like the viable options. C has the advantage being callable from pretty much anything, letting us do native UIs. I'm not sure how good Rust's C interface is; I know there is a library for Cocoa, not sure about Win32 and Qt/Gtk.

[shadowfacts]

C is a good candidate for performance/low overhead and cross-platform compatibility. andlabs/libui is good for cross-platform native UI, but I"m not sure how viable it is to use for the MC launching portion of it

[Gaelan]

MC launching is just automatically assembling all the command line arguments to Java/MC, then running the command. Definitely doable from C.

[MaPePeR]

For the most stuff you can use posix. Even networking with C on Windows is very easy to do cross platform.

We could write the core in Java and use the JNI

That is a horrible idea. We should stick to one language and not create a monstrosity that uses n different programming languages.

[Turmfalke2]

I feel like java would be good idea, everyone needs it for minecraft anyway. Also is there any reason why the launcher should continue running once minecraft is launched? Surely we don't need the launcher just to fancy up stdout and stderr.

[gjgfuj]

Some log program is definitely important. But don't use java, it's horribly
inefficient. Use a natively compiled language.

On Fri, 27 May 2016, 9:44 PM Turmfalke2 notifications@github.com wrote:

I feel like java would be good idea, everyone needs it for minecraft
anyway. Also is there any reason why the launcher should continue running
once minecraft is launched? Surely we don't need the launcher just to fancy
up stdout and stderr.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AC1W3CzCch45qfTKR9Rh_SSafdOATTNpks5qFtkOgaJpZM4Idqt_
.

[acun1994]

As long as some form of the console is visible, that should be enough. Assuming the Vanilla launcher is used like in Curse, then there's no reason to leave this launcher open

[gjgfuj]

Of course, that's true. I would be more for "drop into very minimal mode
until subprocess closes then start again" so I wouldn't have to launch the
program again if it crashes.

Also please don't only use the vanilla launcher it's slow, unoptimized
garbage, but that's just my thoughts.

On Fri, 27 May 2016, 9:46 PM Alvin Soo notifications@github.com wrote:

As long as some form of the console is visible, that should be enough.
Assuming the Vanilla launcher is used like in Curse, then there's no reason
to leave this launcher open

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AC1W3FhtNdzaC7Que8EKv1m8d1WEP1K0ks5qFtmxgaJpZM4Idqt_
.

[Turmfalke2]

Why do we need to any additional logging while minecraft is running, what would you log? Just redirect the output to file and if someone wants to look at it he can open it.

[acun1994]

To get a progress report on what the launcher is actually doing. However, you have a point, since recent forge versions have that displayed on the main loading screen...