Wireless programmers ignore networking issues

Reviewed design and protocol of data exchange between a mobile device and a server recently. It was no surprise that the same old, naiive approach to programming networked transactions is implemented. Client will compose a long string (really long string) consisting of URL and another one, under the covers, the body of HTTP request, with headers and stuff. When done, it will begin transmitting it. And it will not expect anything in response until it's done sending. Seeing anything wrong with that approach? While current wireless networks boast great bandwidth, making a connection and having the first bytes of transmission appear on the other end of the wire takes a sizable time to see. Which causes even smallest of transactions to appear intolerably slow.
Solution exists:

• the client must expect response from the server the very moment it estabilished connection;
• reading must be performed in parallel with writing;
• server and client must agree on the fact that every session of data exchange is not atomic, every session must be divided in smaller bites;
• it also holds true that the server must send the piece of information in response to every such bite-sized transaction as soon as it's done, should not wait till all transactions in request are processed

The benefits:

• network latency is reduced
• application liveliness and user-frendliness is improved
• less memory is needed on client and the server to complete exchange

The complications:

• can not use IWeb interface in BREW, must program sockets; (J2ME is so much better in this regard, got a connection - have a DataInput/OutputStream)
  
• must program multiple threads (again, screw BREW);
• object-oriented approach on the server gets non-trivial, as operations have to be performed on-the-wire, meaning server has to operate on input and output streams and not on collection of transactions
  

These complications prevented our partner from responding positively to our suggestion to revise the protocol. But they are supposed to be professionals in wireless programming field! Why have they not come forward with this approach in the first place? Oh, well. My conscience is clear and when they hit the wall trying to communicate the state of application on a wireless client to several other such clients, I'm going to tell: I told you so.

Published this over on JavaLobby, hopefully it can be discussed there.