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

[Rich E]

On Sun, Jun 3, 2012 at 9:33 AM, s p <sebpiq at gmail.com> wrote:

> > 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.
>
>
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.


> > 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.
>
> 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.

Cheers,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120603/f234e27f/attachment-0001.htm>