The problem as I see it Mecki is that we have effectively two kinds of arrays in JSON; name/value pairs and sequential arrays. So perhaps I'm over-complicating but it seems problematic to represent scalars, NVPs, and sequential arrays with dynamic arrays - at least in a way that would allow the input to be decoded and re-encoded into an identical JSON string.
I understand the concept of not going deeper than 4 dimensions but we've found that we can harness the power of the server to generate a lot of information very quickly (think of it like multiple simultaneous report requests) and then send it all back in one data stream for rendering via the web server. This is smokin' fast compared to trying to read each record over the connection and do the reporting logic from the PHP side. Our menu structure itself is a nested PHP object that can go to any number of levels. We can build such a thing easily in BASIC and send it to the web server no problem but if the web server wanted to move that depth of information into Unidata, well, it's a bit more involved. And as to why JSON vs. XML, especially when Unidata already supports XML, I gotta go back to one of my fundamental TCP/IP lessons: If you want data to move faster on the wire, move less of it! JSON can move the same information as XML (structurally speaking) but with a lot less bandwidth. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
