--- In [email protected], David Adams <dpad...@...> wrote: > > I'm working on a system that transfers data from a back-end to Flex > for display and manipulation. In this case, I can control the message > format on the server-side. I'm pretty happy sending XML because of how > easy it is to work with XML in Flex. On the other hand, XML is > sometimes ridiculously inefficient as a message format as it tends to > be pretty bloated. I'm imagining a few strategies: > > * Strip and reduce the XML to use stupidly short element names and no > spare white-space to reduce the message size a bit. > This is a weak option in a lot of ways but it's easy to do. > > * Compress the XML and decompress it in Flex. > This is an appealing option as I get to work with the XML but don't > have such big messages. Unfortunately, I haven't been able to get this > to work using zlib and ByteArray.uncompress(). I'll also assume that > there is some kind of sweet-spot when the cost of > compression/decompression outweighs the cost of the larger message. > Once I get this working, I could try to figure out when compression is > worth engaging and then have the server compress when it (guesses) it > will make sense. > > * Use AMF. > Can't. It's not supported on the server and a project constraint is > "thou shalt not implement binary protocols by hand." > > * Use a custom binary format, package the data that way on the server, > and then write a custom parser in Flex. > Can't. See previous point and another project constraint, "thou shalt > not invent new binary formats." > > * Use another binary format that Flex does understand. > Are there any? > > Basically, I'm looking for an efficient message transfer format that I > don't have to invent or hand-code.
Plain text. Long before the invention of XML, developers used csv or csv-like files to power their data-driven apps. You'll have to load the plain text into objects, but hopefully you don't have a constraint against that :o)
