Define a standard layout for tool servers

[szschaler]

This should include where the standard expected files, including the tool configuration will be expected.

[jgsuess]

I am very interested in the outcome of this ticket. Are you intending to lay the artefacts out in the way that Maven does it? Or do you intend to have your design? One of the most challenging aspects of Epsilon is the fact that modules do not have structured names. Deeply nested Java package names are ideal To avoid ambiguity. However, they are not much fun and terms of structuring the program. Conversely, flat include structures as they occur in python or C++ are often extremely messy.

[barnettwilliam]

Thanks Jörn, there are two parts to a tool server its tool functions and static files (config, highlighting, and icons).

There are no particular restrictions on the language used to create a tool function just that it should conform to our http json api. The existing tool functions are java based and have a maven structure which as you mention are deeply nested. You have to rely on your ide to make this manageable. The tool functions can be found mdenet/platformtools/services.

The static part contains tool specific files that should be made accessible to the platform e.g. by hosting them on a webserver. These tool files are used when a platform user starts an activity that depends on the given tool. The static part is an npm javascript project that contains a tool configuration file, ace highlighting rules, and icons. The static parts can be found in the platformtools folders named "static.[tool name]".

Because there is no restriction on the language that can be used to create a tool service, we plan to define the expected structure of the static artifacts that the platform uses when loading an activity. So the development project structure is up to the individual developer. The tool functions are made available through a web address e.g. deployed as cloud functions that the tool config file references.