> what _is_ the array? Is it a patch? A canvas? A file?
When you use a dictionary, the name of the key is helpful in clearing this
up.<br><br>Well ... this just cosmetics ... I think the array is very flexible, in that you can just stuff objects in there. And, there will be arrays anyways. What you suggested is actually not possible : <br><pre><br>{
"elements" : {
"obj" : {"id" : 0, "type": "osc~", "args": [440]},
"obj" : {"id" : 1, "type": "dac~"},
"connect" : {"from": [0, 0], "to": [1, 0]},
"connect" : {"from": [0, 0], "to": [1, 1]}<br> }<br>}<br><br>In a map, keys need to be unique. So, you would need to write :<br><br>{
"elements" : {
"obj" : [<br> {"id" : 0, "type": "osc~", "args": [440]},
{"id" : 1, "type": "dac~"},<br> ],<br> "connect" : [<br> {"from": [0, 0], "to": [1, 0]},
{"from": [0, 0], "to": [1, 1]}<br> ]<br> }<br>}<br><br>Which imo, is not much better than :<br><br>[<br> {"class": "object", "id" : 0, "type": "osc~", "args": [440]},<br>
{"class": "object", "id" : 1, "type": "dac~"},<br> {"class": "connect", "from": [0, 0], "to": [1, 0]},<br> {"class": "canvas", ...},
]<br><br>in that there is less nesting, it is thus a bit simpler... but I guess that's a detail.<br><br>> It can also simplify parsing order<br><br>That's true ...<br><br>> I think [GUI info] deserves a classification higher than 'extra info'. A formal extension of the format, so to speak, since the majority of use cases involving a pd patch will require a visual layout.<br>
<br>That's a very good point, ... it's a good idea to specify GUI infos, for better interoperability, but it should be explicitly said that this is optional information, and parsers must handle the case when those are missing.<br>
<br>@Jonathan : Yes, backward compatibility is mandatory, in that the new format must be a subset of the old format - I mean, "semantical" subset : it must be able to contain all the infos contained in old file format<br>
And we suggested to write a converter to help this.<br></pre>