Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data file format is unreadable #28

Open
verhoevenv opened this issue Nov 3, 2014 · 3 comments
Open

Data file format is unreadable #28

verhoevenv opened this issue Nov 3, 2014 · 3 comments

Comments

@verhoevenv
Copy link
Owner

The .dat files are unreadable, unwritable and unmaintainable. We should move to either something more readable (JSON-like?) or a full-blown scripting language.

It seems useful that we can either keep the current format working, make the new format backwards compatible or provide tools to migrate to a new format.

The new format should not be less powerful, in the end.

@Enet4
Copy link
Contributor

Enet4 commented Nov 4, 2014

I would go for an existing base format such as XML or JSON, but maybe we can obtain nicer scripts with a new notation.
But I think we should look at the full data model first. Do you happen to have a diagram, or something describing the models and their relations?

@verhoevenv
Copy link
Owner Author

Thing is that it's not only data. The effects and conditions are actually behavior. This means we will only get so far with JSON or XML or such thing. It's very limited sorts of behavior, which we could keep as such with some renaming, but it might be a good idea to move to a scripting language in which we get all sorts of conditions and effects for free simply by exposing the right objects + the inherent control structures.

@Enet4
Copy link
Contributor

Enet4 commented Nov 8, 2014

Sure thing, but if you think of it, scripts ARE data with a syntax. The only main difference is that a script always describes a workflow for some task. JSON or XML is still a superset in terms of what can be represented.

Anyways, we could look into a mid-term, such as JSON with some strings containing interpreted code in some other (possibly custom) language.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants