<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Question: do you care about backwards compatibility, or is it a non-issue?</span></div><div><br><span></span></div><div><span>-Jonathan<br></span></div><div><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> s p <sebpiq@gmail.com><br> <b><span style="font-weight: bold;">To:</span></b> pd-dev@iem.at <br> <b><span style="font-weight: bold;">Sent:</span></b> Sunday, June 3, 2012 9:33 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [PD-dev] [
pure-data-Feature Requests-3531000 ] Proposal for an alternative file format<br> </font> </div> <br>
<div id="yiv509670485"><pre>> Strict json has a dictionary as it's outermost object.<br><br>I don't think this is true. I was not sure so I checked the spec : http://www.ietf.org/rfc/rfc4627.txt?number=4627<br>
and apparently a valid json string is either an array or an object.<br><br>> Most parsers will accept an array as you have done, but not all (Obj-C's TouchJSON as an example)<br><br>TouchJSON's says (<a rel="nofollow" target="_blank" href="https://github.com/TouchCode/TouchJSON#invalid-json">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:
http://www.jsonlint.com/ "<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.<br>
<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>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.<br>
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>
<br>For example, if I take the example I had given before :<br><br><i>[
</i><i> {"class": "obj", "id": 0, "type": "osc~", "args": [440]},
</i><i> {"class": "obj", "id": 1, "type": "dac~"},
</i><i> {"class": "connect", "from": [0, 0], "to": [1, 0]},
</i><i> {"class": "connect", "from": [0, 0], "to": [1, 1]}
</i><i>]</i><br><br>// start parsing, in pseudo-code<br>foreach element in element_list {<br> if (element.class is "obj") {<br> obj = create_new_obj_with_type_and_args(element)<br> if (has_display_infos(element)) {<br>
set_object_display(obj, element)<br> } else {<br> set_default_display(obj)<br> }<br> }<br> // ...<br>}<br><br>what I mean is that the core specified should be small : objects, connections, data ; and if a particular program (pd, libpd, ...) using this format wants to add extra-info, it should handle the case where those infos are not available when parsing.<br>
Or at least, that's my opinion :)<br></pre>
</div><br>_______________________________________________<br>Pd-dev mailing list<br><a ymailto="mailto:Pd-dev@iem.at" href="mailto:Pd-dev@iem.at">Pd-dev@iem.at</a><br><a href="http://lists.puredata.info/listinfo/pd-dev" target="_blank">http://lists.puredata.info/listinfo/pd-dev</a><br><br><br> </div> </div> </blockquote></div> </div></body></html>