>>>>>Is it possible somehow to send binary data through mssoap 3.0 web service? I am trying to return a string full of compressed characters, but the web service chokes...
>>>>
>>>>If you have control of both ends, strconv(lcstring,13) to send, and strconv( lcB64string,14) to unpack for consumption on the other side.
>>>
>>>Wouldn't that negate the benefits of passing a compressed string in the first place ?
>>>Regards,
>>
>>Not necessarily, i.e. not much. If a string compressed at 1:10 that's factor 0.1, the base64 decompresses at 1.3 or so, that's still factor 0.13 altogether, so instead of 1:10 you still get about 1:7.5. Far better than uncompressed, and still seven bit.
>
>We don''t know what form the compression took or the definition, in this instance, of a 'long' string. You're likely being optimistic in expecting a 10:1 compression ratio. Factor in to that the overhead of 4 compression/decompression processes and, given a reasonable bandwidth connection, it still might not be worth it......

Most of text to transport nowadays being XML, I assumed 1:10 - which is the regular ratio for DBF files, anyway. Also, the zip technology is around for almost 20 years and is actually the mechanism behind the open document format - which is a bunch of xml files zipped (just rename one of them to .zip and look inside), and with today's processors, takes a fraction of time compared to how long does it take to pass a string across the cable (or a large number of cables stretched between various computers). Base64 encoding/decoding is also rather trivial and probably done in straight C, if not machine code.

YMMV, of course, but IMO well worth a try. Base64 encoding will always add the same amount - factor 1.3 or so, and even the worst compression - that used by Windows on compressed volumes - achieves at least 0.5, giving about 0.65, which in this worst case scenario may mean the difference between sending three blocks vs two blocks of data across the wire.