Split `%chess` and the interface into separate repos?

[ashelkovnykov]

Seems like this might be the correct thing to do. Because of the Urbit HTTP API, the frontend is basically just an agent that lives in the browser that talks to the %chess agent on a ship. Plus, it would allow us to do things like:

• Other interfaces (e.g. terminal interface?)
• Split up the licenses (MIT for %chess, GPL3 for the frontend)
• Clean up the build system

[ashelkovnykov]

@bonbud-macryg @rovmug-ticfyn @brbenji @tomholford Looking for input on this idea

[bonbud-macryg]

You pointed out some old code in %chess from before it had a frontend and I left a XX: in there about either removing that stuff or specifically supporting it. Retooling that where possible to play Chess in the dojo would be crazy. I also like the idea of %chess being somewhat functional without a frontend. (If that's what it takes to escape JS...)

It would also be very "urbit" if people were globbing their own frontends onto %chess and distributing them among their peers, all of those versions sharing a common backend. Splitting the repos might make that a little easier, but does it risk making DevEx more annoying than it currently is?

I have no sense of how important licensing is, so defer to you.

[brbenji]

I like the idea!

If %chess is meant to be a teaching ground for what Urbit can do, I think this does it. If a new developer is brought in to improve %chess, it would be a great paradigm shift to see the Urbit backend as its own complete thing. And the point would be driven home right when they follow the ReadMe for setting up the Dev environment.

“The front end is just a facade and all the javascript is vestigial. We’re waiting for the chance to be rid of it.”

terminal interface

Early on I had the conviction for %chess in the terminal.

Here are some of the inspirations I came across:

• chs —play against stockfish, in python
• uchess—play against uci, in go
  • uchess described in an article
• gnu chess is the grand daddy
• hoon school competition, this summer had challenges for creating borders and justifying text in dojo

[ashelkovnykov]

More discussion about this on issue #43 - including broadening the proposal to split the code into three repos, not two.

Unmentioned in the linked discussion, but occurring to me now: storing the app details in a third repo offers several benefits:

1. Cleanly separates the code by language (no more Hoon + JS + bash)
2. Makes iteration cleaner, since the core code is now unrelated to the release process
3. Makes the core repos more immune from details like how Landscape handles app distribution

[bonbud-macryg]

@ashelkovnykov Splitting into three repos sounds good to me but I haven't used GH quite enough yet to have a very well-informed opinion on this. As long as it's easy enough for devs to use - "How quick and easy is it to onboard an App School finisher? Assuming no more experience than the %chess repo currently does" might be a good measure of that - I'm happy with however you decide to split it up.

[ashelkovnykov]

I think this has been resolved positively, and there's now an issue to track the work: #106.