User tec goblin pointed out a few additional benefits to me: 1) Use the Compendium for an external app as well. So that we put in
7thSea data in the compendium, users who want a full table-top
experience use roll20, but users who just want a quick aid in their
phone can use a dedicated app for that. This app could get the
compendium data. 2) Right now most of the logic has to be written as
scripts just for roll20. It's very hard to reuse those scripts in
another application, as they mix presentation and business logic, and as
we cannot use our own libraries. I would think of another approach,
using an external bot (for an example see that: <a href="https://channel9.msdn.com/events/Build/2016/B821" rel="nofollow">https://channel9.msdn.com/events/Build/2016/B821</a> )
How that works? The chat message is sent to roll20 infrastructure (as
now), then you can integrate with one or multiple external services
which can provide additional logic (can recognise for example some
commands). This external service could have the same logic (rolling
dice, handling powers etc) regardless of whether it's integrated to
Skype, Slack, roll20 or a custom application. What would be specific for
roll20 would be the presentation logic (we would have just to present
the appropriate html for a given json response). This would become even
more trivial if we had access to some kind of javascript templating
library. This would both make roll20 more open, it would make us
chose or reuse our own language for logic, but would also help you
benefit from developments in other bots (translation, AI, 'fuzzy'
commands). Even the standard example in MS bot framework (ordering
pizzas from Domino) would be easy to integrate, and some users might
actually want to integrate it in their roll20 the possibility to order
pizzas ;). I think point two is worth special mention as generalized programming (instead of complicated in-sandbox debugging) would speed up development of applications for the game.