thank you, Orion.
however, there seem to have been 2 votes already, 1 for (a), and 1 for (b).
I've just voted for (a).
My reasoning was:
The syntax may be special and different from nowadays formats JSON, XML, etc, but it is so simple and compact
that it can be immediately understood.
It is human-readable, compact, can be easily diffed using text comparison tools.
It compresses well.
It can be easily extended using our 0 !xyz syntax.
Writing a parser for it is quite simple.
I do not like the idea of putting second-level wrapper file(s) around the existing *.dat's.
In the long run, however, we might need a more fundamental change:
I think it would be better to store parts in JSON format instead of the proprietary *.dat syntax.
They could reference each other as usual.
It would be much easier to add new syntax to them.
However, that solution is only feasible if we have a converter tool from *.dat to the new JSON standard
AND (!) back.
That'll be the only way to still be able to use the existing tooling.
One after the other, the tooling could learn to use the new JSON syntax.
HOWEVER, at the moment
- no such converter tooling exists
- no JSON syntax proposal exists
, so in THAT case my vote is (a)
until we have these available.
Creating a wrapper layer to me just appears as an intermediate solution or - to use the hard word - workaround.
My suggestion is to create a JSON syntax suggestion and converter tools,
then setup a new vote.
however, there seem to have been 2 votes already, 1 for (a), and 1 for (b).
I've just voted for (a).
My reasoning was:
The syntax may be special and different from nowadays formats JSON, XML, etc, but it is so simple and compact
that it can be immediately understood.
It is human-readable, compact, can be easily diffed using text comparison tools.
It compresses well.
It can be easily extended using our 0 !xyz syntax.
Writing a parser for it is quite simple.
I do not like the idea of putting second-level wrapper file(s) around the existing *.dat's.
In the long run, however, we might need a more fundamental change:
I think it would be better to store parts in JSON format instead of the proprietary *.dat syntax.
They could reference each other as usual.
It would be much easier to add new syntax to them.
However, that solution is only feasible if we have a converter tool from *.dat to the new JSON standard
AND (!) back.
That'll be the only way to still be able to use the existing tooling.
One after the other, the tooling could learn to use the new JSON syntax.
HOWEVER, at the moment
- no such converter tooling exists
- no JSON syntax proposal exists
, so in THAT case my vote is (a)
until we have these available.
Creating a wrapper layer to me just appears as an intermediate solution or - to use the hard word - workaround.
My suggestion is to create a JSON syntax suggestion and converter tools,
then setup a new vote.