Re: How to transmit complex data to client?

What do threads or multiple processes have to do with the format in which you want to transfer data to the client?

The current vogue is to use JSON as a transport format.

I would also think about using XML together with an XSD, if the client is not under your control. Having an XSD makes communication between you and the other developer(s) much easier, as changes to the protocol will be documented through the XSD.

Comment on Re: How to transmit complex data to client?

Replies are listed 'Best First'.
Re^2: How to transmit complex data to client? by jdrago999 (Pilgrim) on Aug 29, 2011 at 21:31 UTC
The current vogue is to use JSON as a transport format. I second the use of JSON for transmitting data from one program to another. Because parsing JSON is generally quite easy and an "Array of Hashes" will become an "Array of Hashes" anywhere (or their language-specific equivalent) you can depend on a certain level of uniformity. Also, since JSON is human-readable it is fairly easy to debug if you can get a dump of the JSON that is being transferred and parsed. I would also think about using XML together with an XSD, if the client is not under your control. Having an XSD makes communication between you and the other developer(s) much easier, as changes to the protocol will be documented through the XSD. Yes - XML + XSD (or even DTD) are more explicit and granular, and can serve for validation later on. If you prefer to stick with JSON all the way, you could use the emergent JSON Schema standard with JSON::Schema in your Perl and something else on the other end.	[reply]

Replies are listed 'Best First'.

Re^2: How to transmit complex data to client?
by jdrago999 (Pilgrim) on Aug 29, 2011 at 21:31 UTC

The current vogue is to use JSON as a transport format.

I second the use of JSON for transmitting data from one program to another. Because parsing JSON is generally quite easy and an "Array of Hashes" will become an "Array of Hashes" anywhere (or their language-specific equivalent) you can depend on a certain level of uniformity.

Also, since JSON is human-readable it is fairly easy to debug if you can get a dump of the JSON that is being transferred and parsed.

I would also think about using XML together with an XSD, if the client is not under your control. Having an XSD makes communication between you and the other developer(s) much easier, as changes to the protocol will be documented through the XSD.

Yes - XML + XSD (or even DTD) are more explicit and granular, and can serve for validation later on. If you prefer to stick with JSON all the way, you could use the emergent JSON Schema standard with JSON::Schema in your Perl and something else on the other end.

[reply]