[PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format

[s p]

> 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:http://www.jsonlint.com/ "

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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120603/4e08bfd5/attachment.htm>