Question: do you care about backwards compatibility, or is it a non-issue?
-Jonathan
From: s p sebpiq@gmail.com To: pd-dev@iem.at Sent: Sunday, June 3, 2012 9:33 AM Subject: Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
Strict json has a dictionary as it's outermost object.
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 and apparently a valid json string is either an array or an object.
Most parsers will accept an array as you have done, but not all (Obj-C's TouchJSON as an example)
TouchJSON's says (https://github.com/TouchCode/TouchJSON#invalid-json) : "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:
And it turns out, jsonlint accepts json with an array as outermost element. Personally, I've always used an array, and many API libraries that I am using for web development return an array as outermost element.
About the optional GUI, my opinion is that pd is firstly a graphical data flow language existing of canvases and objects with specific location.
Once again (sorry :) I disagree ... True, "pd is firstly a graphical data flow language". However, times they are a changing, and libpd is becoming more and more important, and will probably continue to grow. 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. 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.
For all those reasons, I think it is a good idea to specify a minimalist file format that doesn't include GUI infos. Of course, it should include special placeholders for putting extra info (where GUI info can be put). 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.
For example, if I take the example I had given before :
[ {"class": "obj", "id": 0, "type": "osc~", "args": [440]}, {"class": "obj", "id": 1, "type": "dac~"}, {"class": "connect", "from": [0, 0], "to": [1, 0]}, {"class": "connect", "from": [0, 0], "to": [1, 1]} ]
// start parsing, in pseudo-code foreach element in element_list { if (element.class is "obj") { obj = create_new_obj_with_type_and_args(element) if (has_display_infos(element)) { set_object_display(obj, element) } else { set_default_display(obj) } } // ... }
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. Or at least, that's my opinion :)
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev