YoRyan, on 19 April 2021 - 12:03 PM, said:
Jonas, what is your opinion on dropping STF in this case?
Hi YoRyan,
First, the answer: I find it difficult to guess how many people are now using the clocks. My guess a few days ago to Chris was maybe no more than 5 to 8 based on
this thread? But may be it is too optimistic. And luckily I haven't finished my next UpDate of my Route AddOn yet. The clocks should then run in there. So I personal would be able to handle a file format changing.
For me the clocks have been a topic for 2 - 3 years, so my subjective impression is eventually wrong anyway :-)
My opinion on dropping STF I have expressed here in the last post of mine:
Quote
Finally, it would be best to leave it up to the user whether it provides one or the other format. OR would only have to give preference to the JSON file if both file types exist at the same time. And then a dialog box would really be appropriate here. It would tell the user that both a clocks.dat and an animated.clocks-or were found and therefore OR will continue to use the animated.clocks-or. That would lead the user to remove one of the two files, whichever is more important to him.
Maybe my last posts here in the thread lead to a wrong impression as far as my motivation is concerned. Personally, I can handle JSON. I find too much punctuation marks are used, but I can understand the criticism of the ambiguity of the STFormat. I am basically concerned with the end user who might be forced to use only JSON files in the future.
And second (the continuation of the next novel chapter, please skip if you fed up reading :-):
In my opinion, there is no standardized MSTS ST format at all, because with almost every dat, wag and eng file (and what they are all called) you always have to know in advance in which order the data is arranged in it. Each STF file has its own format. And files like "sigscr.dat", which also have the suffix dat, can hardly be understood as an ST format in our MSTS sense, rather as an external C file.
I see and therefore even welcome a more unambiguous file format, such as the json format, in which each date is provided with an identifier.
And at the same time I think it's maybe a bit of a shame that we (OR) didn't define our own format, a kind of hybrid format that combines the advantages of STF and JSON. Like JSON, consistently with an identifier in front of each date and only brackets as punctuation marks as in the STF, a kind of hybrit format this way:
ClockItem(
ClockSName( Uhr01_Jm.s )
ClockType ( analog )
)
ClockItem(
ClockSName( Uhr02_Jm.s )
ClockType ( analog )
)
ClockItem(
ClockSName( Uhr03_Jm.s )
ClockType ( analog )
)
ClockItem(
ClockSName( Uhr04_Jm.s )
ClockType ( analog )
)
instead of this:
[
{
"Name": "Uhr01_Jm.s",
"ClockType": "analog"
},
{
"Name": "Uhr02_Jm.s",
"ClockType": "analog"
},
{
"Name": "Uhr03_Jm.s",
"ClockType": "analog"
},
{
"Name": "Uhr04_Jm.s",
"ClockType": "analog"
}
]
It is clear to me that JSON with its two different brackets complies with the inheritance syntax of many object-oriented programming languages. But here I think that it should be left to the parser to assign them to program objects instead of expecting the user to use the correct bracket.
About the clocks.dat: As mentioned in my previous post, files like the clocks.dat or the turntable.dat are one-way data transfers from the (end) user to the application. In my opinion there is absolutely no reason why OR should ever write a clocks.dat or animated.clocks-or. Here the user wants to tell the application which clocks or turntables are available, not the other way around. And we (OR) will always be able to read STF. So why not the clocks.dat?
And if there should ever be editors for external files, they can be able to also read both, depending on which format the user has ready.
I think the argument of the amount of code for reading in is very smart, YoRyan, but it seems a bit 80s style to me when it comes to RAM limitations :-). But maybe I am wrong here and overlooking future devices with a lack of memory, such as cell phones or notebooks or playstations, etc. After all, the code for reading STF will always remain in OR.
My current state of knowledge on the subject of JSON files is:
The criterion that basically new OR files can only be introduced in JSON is wrong (only my opinion, no emphasis). Rather, I would say that new OR
dual-way files are to be written in JSON (or in the above-mentioned own OR hybrid format), but the format of
one-way files is decided by the user, at least with one-way files that are readed
by OR only once while an activity start.
I hope this was now with less emphasis, in spite of the details again, all the writing here is exhausting for me too. I hope I've been reasonably factual and have been able to express all of my thoughts on the subject here and in the last few posts.
Best wishes
Jonas