Should Javascript DAPIS be reimplemented as a plugin, or even be suppressed ?

[jlirochon]

JavaScript DAPIS functionality is known as Rhino in the project, because it's the name of Mozilla's javascript engine for Java.

As part of #128, I'm looking for a way to remove Rhino calls from Glowstone's EventFactory.

Actually Rhino is called by the following methods:

• onPlayerChat
• onPlayerJoin
• onPlayerKick
• onPlayerQuit
• onPlayerInteract

The same methods are actually sending events to Glowstone's registered plugins, so I can't see a valid reason to hook JavaScript DAPIS directly into Glowstone's code. It could be converted to a Bukkit plugin for example.

Should this functionality be suppressed ? A similar functionality exists in ScriptCraft plugin (compatible with Bukkit)

What do you think ? Does it make sense ? or am I missing something ?

[DefinitlyEvil]

Yes, I'm sure it is possible. ;)

[jlirochon]

@TheMCPEGamer @DefinitlyEvil @QuarkTheAwesome what do you think about ScriptCraft ? Can we replace our JavaScript DAPIS with it ?

Especially, take a look at their event listeners documentation

Does JavaScript DAPIS provide something that ScriptCraft doesn't ? It looks like it's a well documented project.

[DefinitlyEvil]

It is quite different than what DAPIS does. In Dragonet, each script will be loaded as a single Bukkit plugin and can easily access Bukkit API. For example, user can do this:

var plugin;
function onLoad(pl){
plugin = pl;
pl.getLogger().info("Blah");
pl.getServer().getPlayer("blah").setOp(true);
}

[jlirochon]

Ok @DefinitlyEvil thank you for the explanation !

ScriptCraft is a Bukkit plugin in which you can load custom JavaScript, whereas JavaScript DAPIS provide a way to write Bukkit plugins in JavaScript.

If this is correct, It seems that none of my proposed solutions are viable, and I will find another one.

[DefinitlyEvil]

Maybe we can make G++ open for 3rd-party plugin manager? Of course that need another change for G++.