a) where is the best place to decode the received stream? Xavier do
this in the GetBodyLineNext when the end of document is reached.
I think decoding should be done on the fly.
What do you mean? Data should be decoded during the receiving, i.e.
without having first the whole body?
Yes, indeed. Most compressions, including gzio, are streaming type. So it is
easy to decode them on the fly.
Of course if some compression is not streamable, then receiving the whole
thing then decompressing is OK.
b) the RcvdStream must contain what effectly received from the server
or the decoded version? In the second case, what received should be
dropped or keeped somewhere?
RcvdStream should contains the decode version.
This has some impact, for example if the Cleanup routine will called.
We should proceed very carefully.
In the meantime I made the changes that I mentioned. It is not
finished because we should discuss and decide about the RcvdStream.
The possibilities that I see are the following.
a) RcvdStream will initially receive the encoded body
pro:
- the code that handle the receiving will remain as is.
cons:
- the encoded part must be removed from the stream before replacing
with the decoded version
- the cleanup procedure will be more delicate (in particutlar if the
stream was not empty at the start) because the RcvdCount will change
after the decoding and because the decode could fail.
b) RcvdStream will receive only the decoded body
pro:
- if needed the cleanup is easier and probably more safe
cons:
- the code that handle the receiving must be reworked, probably using
an internal variable that points to FRcvdStream (if no decode is
needed) or to the stream that will be decoded.
- RcvdCount can have some side effects on existent application
Coded version should remains purely internal to the component. Should that
coded version be of some interest (but why ?), then maybe an event or a
new
property could give access to it.
The only reason that I see is for debug, in particular for the
decoding routines.
In the component, where received data is written to RcvdStream, it must be
written to the decompression stream, and then the decoding stream is read to
get decompressed data (if any: you don't always have decompressed data each
time you write compressed data) and written to RcvdStream where it is
available for the application.
RcvdCount, used for determining the end of document, must represent the
compressed byte count.
Maybe be the component has to use another variable for that purpose
(determining when document is complete) and still expose the decompressed
byte count in RcvdCount property. Doing so will make decompression
completely [well, mostly] transparent to applications. I see a potential
problem: RcvdCount is used by application to update progress bar, so it must
be compressed byte count. But other applications use it to know how many
bytes to process, so it must be the decompressed byte count. We can't have
both ! So a choice must be made. I don't know what the best is. Any opinion
?
btw: Xavier, are you listening ?
--
[EMAIL PROTECTED]
http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
