Passing data between languages

[Mark Yedinak]

Is the variant data type well enough defined that a specification can be given to programmer's using another language that they could decode/encode variant data? I am working on a messaging interface that will pass messgaes between LabVIEW, Python and possibly C/C++. Obviously within LabVIEW variants are a very convenient way to pass generic data around at the lower levels of a messaging API. However, the format of the data when flattened to string to pass over TCP connectons is rather daunting. Is my best option to change my lower level code to use a more conventional and defined data structure (basic a simple stream of bytes) and then parse that ino meaningful constructs in LabVIEW? That is, where I currently have variants should I replace them with a string and then at the appropriate places decode that into a cluster. Taking this approach would allow me to define C style structures which can be easily read/transmitted in other languages.

[ned]

I haven't looked closely at the flattened representation of a variant. One major advantage of a variant over a flattened string is that a variant doesn't need to be flat - it can efficiently wrap standard LabVIEW data without making a full copy. However, as soon as you flatten that variant to a string to send over the network, you lose that advantage. The flattened string representation of LabVIEW data is well-documented and has not changed (except to add new data types) in quite a while, if I'm not mistaken. Have you considered using a flattened string instead?

[gb119]

From comments that Rolfk (the maintainer of LabPython and LuaVIEW) jas made, I suspect that this is prpbably difficult to the point of being impossible.

[Aristos Queue]

Google this: JSON

[ShaunR]

+1 for JSON.(strings)

Strict typing is for wimps.

Edited August 5, 2012 by ShaunR

[jzoller]

Using JSON for this as well.

[Onno]

XML and JSON are probably much better options for inter-language communication. Not in the least because that's the way people have solved this problem before.

XML is of course well-supported, but I'm not sure about JSON. There's a Labview-JSON library, but that only works for encoding JSON, not for decoding it.

[Rolf Kalbermatter]

From comments that Rolfk (the maintainer of LabPython and LuaVIEW) jas made, I suspect that this is prpbably difficult to the point of being impossible.

Actually that remark was specifically targeted at accessing variant data directly from the C side, eg, allow to pass Variants to the LuaVIEW DLL and do the right thing in that DLL. The C interface to Variants, while it exists and gets used in some small manner by DAQmx and some other NI drivers, is undocumented so far.

I think the Flattened Format of a Variant would look mostly similar to the Flattened format of other data in LabVIEW with the addition of Variant properties added in. I also believe that the LabVIEW documentation does even document that format to some extend, but it's been a while that I looked at that. In fact the OpenG LVData package implements that approach sort of.

But flattening a Variant to pass it to LuaVIEW is while possible, very supoptimal and I don't like the idea to implement it in such a way.

[Mark Yedinak]

I took a look at JSON and I definitely like it better than XML. The problem in this particular case is that I will have binary data as part of the data set and JSON doesn't look like it supports that very well. I will probably just define the data format using a basic C style structure and decode/encode it in LabVIEW.

[Aristos Queue]

You can encode binary data in the string of JSON.

[ShaunR]

I took a look at JSON and I definitely like it better than XML. The problem in this particular case is that I will have binary data as part of the data set and JSON doesn't look like it supports that very well. I will probably just define the data format using a basic C style structure and decode/encode it in LabVIEW.

I use base64 because everyone has base64 decoders and it has the benefit that images can be planted straight in a browser without explicit conversion (although that's probably not much of interest for your use case)

[Rolf Kalbermatter]

I took a look at JSON and I definitely like it better than XML. The problem in this particular case is that I will have binary data as part of the data set and JSON doesn't look like it supports that very well. I will probably just define the data format using a basic C style structure and decode/encode it in LabVIEW.

You could also use an array of bytes to encode binary data, although it is a little more verbose than a base64 scheme stored as string. Unfortunately JSON does not seem to provide a standard for encoding numerics in a different than the decimal base.

Or since a JSON string is actually 16 bit Unicode, you could encode it as a string of "\uBEAF\u1234\u.....". Still more verbose than base64.