Ralph Johnson wrote:
I think your mentioning of bytecodes comes from a misconception - a Delta carries source code, but it is *not* compiled when loaded into an image. The compilation is done in the "next step" - when you "apply" the Delta to the image (using SystemEditor to do it atomically).
Yes, I misunderstood what you meant by "compiler driven" and that you thought it was OK to use the compiler to apply the delta, but wanted to read the delta into the image without using a compiler.
Given that, I agree that JSON is a good match for your needs. I don't think you should use netstrings.
Right, now I started looking into Yaml which solves a few "issues" that JSON has but on the other hand - the spec is huge and it is not as widely known/understood.
Problems with JSON:
- No "typing". For this use we probably don't care, we can just "type" our objects ourselves using some kind of String key. Yaml has some type system, not sure if it is nice.
- Not so good handling of Strings. This was why I was thinking about netstrings. In fact, this one is a killer in some ways, if we can't have CRs in the file then we surely can't get "readable code". Yaml has "literal blocks" which means we can easily have readable code.
Problems with Yaml:
- Spec is HUGE. Even though we could use a handwritten parser/producer and only use exactly the subset we need (approximately JSON subset), it is still hard for people to understand etc. And not nearly as many implementations in other languages around.
The code for Json in Squeak (available on SS) is a single class, and the code is trivial. We could probably extend it to deal with "verbatim source" - but then it would not be standard Json anymore.
Hmmm. :) I am leaning towards a handwritten Yaml parser/producer that only uses a tiny, tiny subset of Yaml that we need. It would then be "true Yaml" although a subset, the code can probably be made as small.
Found a very interesting blog article comparing the two:
http://blog.ingy.net/2007/05/yaml-and-json.html
regards, Göran