>> You don't need to change the FTP component or any other else. It takes >> careof everything. You should only change TWSocket because you don't want >> to dothe initi in your application. > So, suppose I inherit a class > TNewTWSocket = class (TWSocket) > ... > AssignDefValues > ... > end > > I don't see how this would affect on TFtpCli which I use
This is exactly what is needed. You don't want to change TFtpCli ! TFtpCli has been designed with the behaviour of TWSocket as it is now and no other. I really wonder why you want to change TFtpCli. The TWSocket behaviour you don't like is not exposed by TFtpCli. > I looked at the sources, and decided that it is safe to remove field > clearing. > Of course this modifications will be for my own apps only, and so on. You can do it if you like. But IT REALLY A VERY BAD IDEA for you ! You'll go into a lot of troubles. I don't see any advantage of doing that. I see only disadvantages. Please explain why you insist on changing that. In the furture, it is likely you will not be able to apply your changes easily as the inner working of the component may change. > But I can find no reasons for that and consider such behavior very > embarassing. Then change it FOR YOUR APP ONLY. And the only clean way of doing that is to derive a new class. > I have never ever saw a class where programmer has to re-assign fields he > already assigned before. Maybe you have not yet seen everything in the world :-) >> As a side note: When you think something must be changed in ICS >> components,then sublit your proposal here, explain why your change is >> needed, eitheradding a new feature or fixing an issue, and let's discuss >> it. If it isapproved, then your change will be done in the component for >> everyone. Onegold rule with ICS is "do not break existing code unless >> really reallyreally needed". > > Yes, I've already reported > (http://lists.elists.org/pipermail/twsocket/2008-August/038568.html) about > it when I nearly chashed my brain on this underwater stone. First time > connection establishes OK, but second time it fails, wth? I've lost hours > before I found the trouble source. That's not a good reason to change that behaviour. > Moreover. Another head-breaking bug-or-feature: necessity to manually > specify binary or text mode. There is no way the component can decide for you. The default is what the standard says. No reason to change that. But if you want, again just derive your own class from TFtpCli and you have what you need. > Another issues: > * External FLocalStream issue, when FTPCli destroys an object which it > didn't create. > * Unuseful host name resolving when using socks5 > - these things I've reported too, but got no reaction. Your messages are not change proposal. They looks like questions. A change proposal must (assuming a bug or optimization): 1) Explain what the issue is and why it has to be changed 2) Show the involved code 3) Show the proposed change 4) Analyse the possible impact on existing code You didn't got any answer because your messages were looking like questions and no one had an immediate answer to your questions or had time to answer those questions (Probably because those questions needed to dig into the code to provide a valid answer). > So what's the meaning of further reporting about exceptions in log and > received file creation if directory doesn't exist, great lack of timeout > mechanism for stopping socket from waiting eternally, and so on? > Looks like I have to implement all needed behaviors by my own. Well, unless you have a proposal which looks very promizing for someone, it is likely that you have to implement it yourself. That's how many feature were implemented in ICS: by volunteers needing such a feature. If you have great features, discuss here about what and why. Take opinion from others. Propose some implementation. Follow the guidelines when coding (There is a doc file in ICS distribution explaining coding style to use). And most important: do NOT BREAK EXISTING CODE or your changes will not be adopted. Breaking changes must be implemented in derived classes. If you can't implement the changes yourself, then you may try to find somone interested by implementing it, either for free or for a fee. That's how ICS-SSL was born: someone needed it and managed to create a group funding the development. Later ICS-SSL was given for free. Regards, -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) 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
