3 ms·

> Which version of language? Which interpreter? Ah, very good question. Currently, it's just whatever version is in /usr/bin/$LANGUAGE. You can see in /home/$US

> Which version of language? Which interpreter? Ah, very good question. Currently, it's just whatever version is in /usr/bin/$LANGUAGE. You can see in /home/$USER/.dit-languages how the language configurations are defined. You can add another configuration, just by copying the Python configuration, changing the name and path to Python2.7, and then doing this: validator Python2.7 {{ //Older python code }} In the long run, this should be made a lot simpler I think, which leads me to your next question: > How do you make sure that both sides of communication run the same logic? This will probably require some way to send language configurations along with a dit. If you send someone a dit which requires Java code, but the client doesn't even have Java, the dit should be able to recover from this somehow, by automatically installing Java, creating the configuration, etc. I'm not exactly sure how this should work, but its one of those clearly solvable problems that I'm trying to leave be until I have a good example of the real problem. > Is the code transmitted together with data? What is benefit of running this code on receiving side instead of sending side? Yes, the code is always tied directly to the data. Currently, source code must be sent, but in the future, it could pull from a link, or even run the validation offsite, via an API (important in case you want closed source classes). In theory, there is no reason for the receiver to run the validation, (assuming the receiver trusts the sender to validate). But one purpose of dit is to prevent a message from ever being separated from it's meaning. If a client receives some data in a dit format they have never seen, they can learn how it works by looking at the dit. The validation code can even be used as ad-hoc unit tests when trying to process the data automatically. And also remember that querying (and converting, mutating, anything else that might be added) also requires the dit code. > Do you serialize and store validation and query code on disk? Is this good idea? Currently, the modified code is regenerated every single time. You can see the code in /tmp/dit/. This is slower, but it does mean that the code and serialized data are always as new as possible. Caching could be an option, if done carefully. > .old data that cannot be queried as well as new data. ...old dates cannot be converted to various date formats while newer can. I'm actually not sure what you mean here, I can't picture how this could happen. Could you explain?

jmiskovic 7y ago
Let's say side A is a logger, with each log entry being timestamped. We want to be helpful so we provide way to convert data into MM-DD-YYYY string. These logs are transmitted to side B and stored to disk. Few months later we decide to add another converter, one that gives out YYYY-MM-DD format. New logs can interpret themselves better than old ones, and side B needs to be careful what it can ask of dit file. If there are multiple log sources, then depending on source we have more or less powerful interpretation of _same_ data type, until they are all updated. To me the code should be stored and managed separately from data. The side B should be responsible for parsing raw data from A. The interpretation shouldn't be bundled with data because same data can be interpreted better in future. The cleanest way I've seen it done is Clojure's spec library for describing and validating data.

jmiskovic 7y ago

Let's say side A is a logger, with each log entry being timestamped. We want to be helpful so we provide way to convert data into MM-DD-YYYY string. These logs are transmitted to side B and stored to disk. Few months later we decide to add another converter, one that gives out YYYY-MM-DD format. New logs can interpret themselves better than old ones, and side B needs to be careful what it can ask of dit file. If there are multiple log sources, then depending on source we have more or less powerful interpretation of _same_ data type, until they are all updated. To me the code should be stored and managed separately from data. The side B should be responsible for parsing raw data from A. The interpretation shouldn't be bundled with data because same data can be interpreted better in future. The cleanest way I've seen it done is Clojure's spec library for describing and validating data.