<br><br><div class="gmail_quote">On Sun, Jun 3, 2012 at 9:33 AM, s p <span dir="ltr"><<a href="mailto:sebpiq@gmail.com" target="_blank">sebpiq@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<pre><div class="im">> Strict json has a dictionary as it's outermost object.<br><br></div>I don't think this is true. I was not sure so I checked the spec : <a href="http://www.ietf.org/rfc/rfc4627.txt?number=4627" target="_blank">http://www.ietf.org/rfc/rfc4627.txt?number=4627</a><br>
and apparently a valid json string is either an array or an object.<div class="im"><br><br>> Most parsers will accept an array as you have done, but not all (Obj-C's TouchJSON as an example)<br><br></div>TouchJSON's says (<a href="https://github.com/TouchCode/TouchJSON#invalid-json" target="_blank">https://github.com/TouchCode/TouchJSON#invalid-json</a>) :<br>
"If you think your JSON is valid but TouchJSON is failing to process it correctly, use the online JSON lint tool to validate your JSON:
<a href="http://www.jsonlint.com/" target="_blank">http://www.jsonlint.com/</a> "<br><br>And it turns out, jsonlint accepts json with an array as outermost element.<br>Personally, I've always used an array, and many API libraries that I am using for web development return an array as outermost element.<div class="im">
<br></div></pre></blockquote><div><br></div><div>I stand corrected. I remember having difficulties using TouchJSON and receiving json with an array as outermost element, but this was a while back and it's clearly supported when I look at it now. To me, it still seems vague this way: 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. It can also simplify parsing order.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><pre><div class="im">
<br>> About the optional GUI, my opinion is that pd is firstly a graphical data flow language existing of canvases and objects with specific location.<br><br></div>Once again (sorry :) I disagree ... True, "pd is firstly a graphical data flow language".<br>
However, times they are a changing, and libpd is becoming more and more important, and will probably continue to grow.<br>Also, I might be wrong, but I am guessing nobody would disagree that it is a good idea to go towards a better separation between pd core and its GUI. </pre>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><pre>When you specify something new, it is a good occasion to do things well and clean. Passing over some legacy stuff to a new specification you are writing kind of kills the purpose of making a new specification.<br>
<br>For all those reasons, I think it is a good idea to specify a minimalist file format that doesn't include GUI infos.<br>
Of course, it should include special placeholders for putting extra info (where GUI info can be put).<br>And as a new parser will have to be written anyways, it is not much extra-work to handle missing attributes that are not mandatory in the spec.<br>
</pre></blockquote><div>I agree with you that graphical representation should be separated out and it should be possible to be auto-generated if not present, but I think it 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. If you let every app define it's own format for graphical layout, there will be no interchange. For example, you can define an optional key such as "layout" that contains well known child nodes like "x", "y", "size", etc. If an element has this, great, if not, an app can generate this data. But at least the parsing will be well known across the possibly many different graphical interfaces.</div>
<div><br></div><div>Cheers,</div><div>Rich</div></div>