They can still pull in external stuff. Having it in source form makes it easy to verify that what they’re pulling in is, say, unmodified Apache Commons-IO, and thus doesn’t need deeper review in itself.
Thats a really good point. Pulling in source shouldn’t be incredibly hard if they look it over good and build it themselves with their own dependencies. Like @teozkr said I think it would actually afford a malicious developer less room to try to trick the reviewers if they had to submit perhaps a compressed project file vs a compiled jar file.
Then why would I even have a buildscript, if people aren’t gonna use it? ^^
I have some thoughts on this.
If Ore compiles the plugin from source we’ll have a few advantages:
- No sneaky obfuscation tricks.
- Modders don’t hide their source code (They shouldn’t be allowed to. Sponge is OSS and their mod should be too.)
- It forces them to use ForgeGradle which will solve all the world’s problems. Right, @AbrarSyed?
EDIT: Grum also mentioned in an IRC chat with me that decompiling and checking for problems is almost pointless since a developer can do a few quick tricks to fool the decompiler.
For the implementation of Ore I have a few suggestions.
- Ember.js frontend. This guarantees a good API, since we will be forced to consume it ourselves. This also separates the client from the server which has numerous technical advantages. For those saying that Ember is slow to load, look at FastBoot which will be released far before this is done.
- Phoenix (Elixir) backend. Currently we are using Python, which is ok but Elixir and Phoenix are mindblowingly fast and they don’t lose much developer productivity. Phoenix also has a very good websocket system (it’s called channels) which will make live updating a breeze. Also, it runs on BEAM so you can set it up as a cluster.
- Service Oriented Architecture (SOA). The mod build system would be completely separate from the other parts.
EDIT: Yes, I can help with some of this.
3 Likes
I agree with a lot of what you said (especially stuff like phoenix and ember, all things that I was considering heavily). However, here’s what the current plan is:
- React/Angular + some sort of data library. I personally dislike Ember for larger applications, and React and Angular both have extremely good ecosystems surrounding them. Choosing client-side frameworks comes down to personal preference, but I have not yet found a data library I like (other than backbone collections).
- Django. The fact that you mentioned Phoenix and Elixir is freaky because I love both a whole lot and have been playing with them on and off for a couple months. However, neither are as well known as the Django + Python combo and once again, Django wins with its superior ecosystem. Python is also far more well-known than Elixir (and it can be argued that the two languages are much the same, even if Elixir is far nicer in some respects). Scaling shouldn’t be a problem now (or pretty much ever), developer productivity should. Django is pretty much the way to maximize that. If scaling does become a problem, we’ll have enough manpower to figure it out.
- I’m not sure about the feasibility of a “mod build system”, since that complicates the whole thing by 10x. But if there was one, yes, it would be a separate service that would simply be called by Ore.
But… that’s the whole point of it. Check out http://emberaddons.com/ to see how good the ember ecosystem is.
Or you could just set up a HTTP load balancer in front.
1 Like