Re: [twsocket] OverbyteIcsMimeUtils.pas - DoFileEncBase64
Piotr Dałek wrote: > Hello! > >> A reliable way to calculate More was >> "More := Stream.Position < Stream.Size;" >> >> however that is slower since Stream.Size has to seek to the end >> of the stream and the back to current position on each call of >> DoFileEncBase64(). (Instead of Stream.Size we could also check >> against file size, however only with ShareMode fmShareDenyWrite). > > var > LocalStreamSize: integer; > [..] > LocalStreamSize := Stream.Size; > [..] > More := Stream.Position < LocalStreamSize; > [..] > > Problem solved. >>> I do not get this, sorry. Please elaborate. >>> >>> Get the stream size only once - store it somewhere and use stored >>> value instead of calling Stream.Size getter. > >> OK, but what will happen if the stream size changes during encoding, >> if for instance the component user opened the file with ShareMode >> fmShareDenyRead? > >> That's why I added public property Mode to the TBufferedFileStream >> class and >> check the ShareMode in DoFileEncBase64,. in case of no problem >> TBufferedFileStream(Stream).FastSize is called (which is current, >> constant size), otherwise Stream.Size (which is slow, but who will >> actually open a file to be sent with ShareMode fmShareDenyRead only >> ? I guess not many). > > The only reason for this is creating attachment (file to be encoded) > while > it is actually encoded, but then, using the mechanism available in > ICS is a > waste of disk space (already encoded original data still reside on > disk). > I think that all users will use simple files containing ready data > that is > not going to be changed during encode process. Supporting other > scenarions > is overkill, at least for me. If you don't agree, then what if you > buffer > (in TBufferedFileStream) 1024 bytes, encode first 50, then (somehow) > next > 100 bytes changes? You still have outdated 100 bytes in the buffer. > Then > what? Bug, no matter what! > So why should you care about size change, > if > you don't care about actual file changes? I don't think that you're > going > to support *that* scenario. True :) But unfortunately it is possible to set fmShareDenyRead and fmShareDenyNone:( I wish there were just two ShareModes provided, fmShareDenyWrite and fmShareExclusive. -- Arno Garrels > -- > Piotr Dałek > enigmati...@interia.pl > > -- > Promocja w Speak Up. 3 miesiace angielskiego gratis. > Sprawdz teraz i wypelnij formularz! >> http://link.interia.pl/f2019 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] OverbyteIcsMimeUtils.pas - DoFileEncBase64
Hello! > A reliable way to calculate More was > "More := Stream.Position < Stream.Size;" > > however that is slower since Stream.Size has to seek to the end of > the stream and the back to current position on each call of > DoFileEncBase64(). (Instead of Stream.Size we could also check > against file size, however only with ShareMode fmShareDenyWrite). var LocalStreamSize: integer; [..] LocalStreamSize := Stream.Size; [..] More := Stream.Position < LocalStreamSize; [..] Problem solved. >> >>> I do not get this, sorry. Please elaborate. >> >> Get the stream size only once - store it somewhere and use stored >> value instead of calling Stream.Size getter. > OK, but what will happen if the stream size changes during encoding, if for > instance > the component user opened the file with ShareMode fmShareDenyRead? > That's why I added public property Mode to the TBufferedFileStream class and > check the ShareMode in DoFileEncBase64,. in case of no problem > TBufferedFileStream(Stream).FastSize is called (which is current, constant > size), > otherwise Stream.Size (which is slow, but who will actually open a file to be > sent > with ShareMode fmShareDenyRead only ? I guess not many). The only reason for this is creating attachment (file to be encoded) while it is actually encoded, but then, using the mechanism available in ICS is a waste of disk space (already encoded original data still reside on disk). I think that all users will use simple files containing ready data that is not going to be changed during encode process. Supporting other scenarions is overkill, at least for me. If you don't agree, then what if you buffer (in TBufferedFileStream) 1024 bytes, encode first 50, then (somehow) next 100 bytes changes? You still have outdated 100 bytes in the buffer. Then what? Bug, no matter what! So why should you care about size change, if you don't care about actual file changes? I don't think that you're going to support *that* scenario. -- Piotr Dałek enigmati...@interia.pl -- Promocja w Speak Up. 3 miesiace angielskiego gratis. Sprawdz teraz i wypelnij formularz! >> http://link.interia.pl/f2019 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] OverbyteIcsMimeUtils.pas - DoFileEncBase64
Piotr Dałek wrote: > Hello! > >> Piotr Dałek wrote: >>> Hello! >>> A reliable way to calculate More was "More := Stream.Position < Stream.Size;" however that is slower since Stream.Size has to seek to the end of the stream and the back to current position on each call of DoFileEncBase64(). (Instead of Stream.Size we could also check against file size, however only with ShareMode fmShareDenyWrite). >>> >>> var >>> LocalStreamSize: integer; >>> [..] >>> LocalStreamSize := Stream.Size; >>> [..] >>> More := Stream.Position < LocalStreamSize; >>> [..] >>> >>> Problem solved. > >> I do not get this, sorry. Please elaborate. > > Get the stream size only once - store it somewhere and use stored > value instead of calling Stream.Size getter. OK, but what will happen if the stream size changes during encoding, if for instance the component user opened the file with ShareMode fmShareDenyRead? That's why I added public property Mode to the TBufferedFileStream class and check the ShareMode in DoFileEncBase64,. in case of no problem TBufferedFileStream(Stream).FastSize is called (which is current, constant size), otherwise Stream.Size (which is slow, but who will actually open a file to be sent with ShareMode fmShareDenyRead only ? I guess not many). -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] OverbyteIcsMimeUtils.pas - DoFileEncBase64
Hello! > Piotr Dałek wrote: >> Hello! >> >>> A reliable way to calculate More was >>> "More := Stream.Position < Stream.Size;" >>> >>> however that is slower since Stream.Size has to seek to the end of >>> the stream and the back to current position on each call of >>> DoFileEncBase64(). (Instead of Stream.Size we could also check >>> against file size, however only with ShareMode fmShareDenyWrite). >> >> var >> LocalStreamSize: integer; >> [..] >> LocalStreamSize := Stream.Size; >> [..] >> More := Stream.Position < LocalStreamSize; >> [..] >> >> Problem solved. > I do not get this, sorry. Please elaborate. Get the stream size only once - store it somewhere and use stored value instead of calling Stream.Size getter. -- Piotr Dałek enigmati...@interia.pl --- Promocja w Speak Up. Kwartal angielskiego za darmo. 3 miesiace nauki gratis. Sprawdz teraz! >> http://link.interia.pl/f2019 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] OverbyteIcsMimeUtils.pas - DoFileEncBase64
Piotr Dałek wrote: > Hello! > >> A reliable way to calculate More was >> "More := Stream.Position < Stream.Size;" >> >> however that is slower since Stream.Size has to seek to the end of >> the stream and the back to current position on each call of >> DoFileEncBase64(). (Instead of Stream.Size we could also check >> against file size, however only with ShareMode fmShareDenyWrite). > > var > LocalStreamSize: integer; > [..] > LocalStreamSize := Stream.Size; > [..] > More := Stream.Position < LocalStreamSize; > [..] > > Problem solved. I do not get this, sorry. Please elaborate. BTW: I uploaded some SMTP changes to the v7 repository. -- Arno Garrels > > -- > Piotr Dałek > enigmati...@interia.pl > > > -- > Zobacz program TV na dzis! > sprawdz >>>http://link.interia.pl/f202a -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] OverbyteIcsMimeUtils.pas - DoFileEncBase64
Hello! > A reliable way to calculate More was > "More := Stream.Position < Stream.Size;" > > however that is slower since Stream.Size has to seek to the end of the > stream and the back to current position on each call of DoFileEncBase64(). > (Instead of Stream.Size we could also check against file size, however > only with ShareMode fmShareDenyWrite). var LocalStreamSize: integer; [..] LocalStreamSize := Stream.Size; [..] More := Stream.Position < LocalStreamSize; [..] Problem solved. -- Piotr Dałek enigmati...@interia.pl -- Zobacz program TV na dzis! sprawdz >>>http://link.interia.pl/f202a -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] OverbyteIcsMimeUtils.pas - DoFileEncBase64 problemdetecting end of stream
> So, do we have to find a fix or is such an additional blank line > in Base64 MIME parts acceptable? IMO it is acceptable. -- francois.pie...@overbyte.be Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be - Original Message - From: "Arno Garrels" To: "ICS support mailing" Sent: Tuesday, January 20, 2009 12:03 PM Subject: [twsocket] OverbyteIcsMimeUtils.pas - DoFileEncBase64 problemdetecting end of stream > Hi, > > When encoded data size is divisible by 72 (line length) DoFileEncBase64() > returns More = TRUE upon the last data chunk even though there are no > more bytes left in the stream. It is because More is just calculated by > "More := (ByteCount = 3);". > In those cases an additional blank line may be inserted at the end of > the Base64 data in the MIME part (if the part isn't the last). > You can reproduce this issue with the MailSnd demo and the file > attachments ics_logo.gif and fp_small.gif. > > A reliable way to calculate More was > "More := Stream.Position < Stream.Size;" > however that is slower since Stream.Size has to seek to the end of the > stream and the back to current position on each call of DoFileEncBase64(). > (Instead of Stream.Size we could also check against file size, however > only with ShareMode fmShareDenyWrite). > > So, do we have to find a fix or is such an additional blank line in Base64 > MIME parts acceptable? > > What do you think? > > -- > Arno Garrels [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] OverbyteIcsMimeUtils.pas - DoFileEncBase64 problem detecting end of stream
Hi, When encoded data size is divisible by 72 (line length) DoFileEncBase64() returns More = TRUE upon the last data chunk even though there are no more bytes left in the stream. It is because More is just calculated by "More := (ByteCount = 3);". In those cases an additional blank line may be inserted at the end of the Base64 data in the MIME part (if the part isn't the last). You can reproduce this issue with the MailSnd demo and the file attachments ics_logo.gif and fp_small.gif. A reliable way to calculate More was "More := Stream.Position < Stream.Size;" however that is slower since Stream.Size has to seek to the end of the stream and the back to current position on each call of DoFileEncBase64(). (Instead of Stream.Size we could also check against file size, however only with ShareMode fmShareDenyWrite). So, do we have to find a fix or is such an additional blank line in Base64 MIME parts acceptable? What do you think? -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
