> What is purpose of this code? Reading until socket error or timeout? > What is practical usage of this? I still not understand why this must be > part of standard POP3 implementation, this is why I am asking you.
Notice that code is based on old synapse code - that is reason why socket error and timeout are not cover here. You may correct it if you accept suggestion. Personally I do prefer freedom of using commands directly on server. Synapse method supports are only "special cases" of sending/receiving getting data to/from server . This however is the basic method of communication. Indy I abandon because I needed simplicity I did found in Synapse, supports this basic approach as well. I find that basic approach should be included in Synapse as well. Second reason you mentioned yourself - using non-standard server commands. Perhap not pressing programmer to make descendant to allow basic approach of communication? My suggestion here is that basic approach is essential feature and it is recommendant to be allowed in Synapse for all services, not for POP3 only. > Default values of range definitons stay on 0. Here is not reason to > change this, because it have only one limitation.. you cannot ask range 0- > 0. That is reason I deliberately set default to -1, this avoid all problems on zero based indexes... In case that file on server have zero or 1b size it require additional preparation in the main application code. No reason to pressing programmer to handle that - no reason why not handling all possible situations inside Synapse. I working here on simple DownloadAccelerator (FTP and HTTP) and for HTTP I created also full stream support. Firs application simply get header manually, compare it with eventually existed file and then simply execute downloading data by given range to collect rest/desire range. Desired range can be also previously received or handling unexpected errors (important point!, see down regarding error 416). > As you can see, you can handle all cases without changed default values > and with full compatibility with old code. My suggested solution is fully compatibility with old code, fix existed bug and also handle all possible situations whit no further code interventions. > > Receiving := Receiving and (FResultCode <> 204); > > Receiving := Receiving and (FResultCode <> 304); > > > > //SZ > > Receiving := Receiving and (FResultCode <> 416); > > I not accept this, because it is wrong! With error 416 you can have body > entity. If you are ignoring this fact and not trying to read it, then you > can have a big problems if you are using persistent connection what goes > out of sync in this case. > > Result codes 204 and 304 is different case, because these responses must- > not have body entity, as is defined in RFC. > > I know, you wish to hide error document response in case 416 error, but > why I must to hide it? httpsend is HTTP protocol implementation, co I am > returning data in HTTP purity. How to handle it, it is work for calling > application. What about a program, what wish to see 416 error document? All that comes from full stream support I have (you planning to create it). I directly gives stream and ranges to the function I modified. What will happend here if given range is incorrect? Or when another unhandled error is returned from server! In this example (given destination to my function is mostly TFileStream), will be added that error report if these errors are not handled. Then it is clear what successive mess this will produce. All that I wrote is from real situations I have had. And all that may happens in current synapse solution based only on TDocument stream. I suggested while ago different approach of handling error messages, where only on positive expected (income of excepted real data) will be also sent back in the stream. Current solution (using one stream for error and data) is potentionally highly dangerous. Anyway, as I wrote while ago in a private message when asked permission to use some basic synapse code for my own library, which I asked because "suggestions I may give here may not be applicable best in current Synapse solutions because slightly different approaches and needs we have". Sasa -- www.szutils.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
