You are correct with regards to the present protocol. The network transmission layers must parse the BLR message formats, which is why message formats are declared up front. They do not, however, have to parse the most complex (and extensible) language semantics. The driving force for this design was that the preprocessor would generate structs/records/whatever in the post-processed program, the message format would correspond to the generated structures, and XDR would be used to map between the message structures and cannonical network form. There was provision, however, that if both ends were the same platform architecture, the data messages could be sent as a byte stream without translation to cannonical network format.
Preprocessor use, of course, has pretty much dropped off the face of the earth. But for your larger question, a self-describing, platform independent data encoding could be used instead of XDR, achieving significant packing density over XDR cannonical network format (and be cheaper to process). For a field, as opposed to message, based system, this is ideal. NuoDB uses such an encoding for all messages. The trick of the encoding is that each value is encoded based on value rather than declaration, so the number "10" would have the same minimal representation whether declared as a 16, 32, or 64 bits. There are lots of ways to structure network protocols. The Firebird protocol, unfortunately, was born in and for a different era. Still, it must servce the existing API, which is embedded in countless thousands of application programs. > On Aug 14, 2014, at 4:49 AM, Alex Peshkoff <peshk...@mail.ru> wrote: > >> On 08/14/14 03:41, Jim Starkey wrote: >> The length is passed so the protocol handlers neither need to parse nor even >> understand BLR. If every transmission layer had to understand BLR, >> extending it would be next to impossible. > > At the moment when firebird forked from interbase BLR parser was already > present in remote subsystem, and it is there now. Certainly, it's > limited parser that understands only BLR, describing message format. And > it's hard to imagine cross-architecture message transfer without knowing > what datatypes are stored in the message. > > > ------------------------------------------------------------------------------ > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
