Re: [twsocket] I wan't to stop the server from listening then start it
On Sat, Nov 1, 2008 at 4:33 PM, Francois PIETTE <[EMAIL PROTECTED]> wrote: ... > 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. That somebody is us (Fastream). We use heavily derived ICS. But sometimes this is not possible. For example for MT technique, we needed to change the code as Anton initially did since we had to modify the listening server code in WSocketS and there is no way to make the THttpServer use that modified class inside by inheritence. Best Regards, SZ -- 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] I wan't to stop the server from listening then start it
>> 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
[twsocket] I wan't to stop the server from listening then start it
Francois, thank you for packages advise. It is quite unulual but looks convenient. > 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 > You should not disable a "strange method" unless you fully understand whatit > does and if it is not used elsewhere. You can of course disable it foryour > own applications or components but surely not for existing applicationsor > components. If you do, you'llk probably break something because > theapplications or components are developped assuming the behaviour > youconsider "strange". 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. > Clearly here, the "strange method" is not a bug. It is a feature. By > designTWSocket reset some properties to default values. There is a good > reasonbehind that design, even if that reason is no more really applicable > today,that behaviour must be preserved because existing code may rely on it. Obviously it is. Bugs look differently)). But I can find no reasons for that and consider such behavior very embarassing. I have never ever saw a class where programmer has to re-assign fields he already assigned before. > 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. Moreover. Another head-breaking bug-or-feature: necessity to manually specify binary or text mode. Also many hours of step-by-step debug. to find an answer why received files are broken. I reported about it, but was said that I should implement mode selection by myself. 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. 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. -- Regards, Anton -- 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] I wan't to stop the server from listening then start it
>> You do not need to "redeclare" the properties; all >> you need to do is override the AssignDefaultValue() >> method, like Francois said. > In FTP client, there are two fields of type TWSocket. Whose > AssignDefaultValue > should I override to stop them from clearing properties? Defenitely not ! >> This method is virtual for precisely this reason. > Actually I still can't understand for which reason this method was made > >> But, in general: yes, that's exactly what you should do. > Sorry, but i dont' wish to do all that things just for disabling a single > strange method. You should not disable a "strange method" unless you fully understand what it does and if it is not used elsewhere. You can of course disable it for your own applications or components but surely not for existing applications or components. If you do, you'llk probably break something because the applications or components are developped assuming the behaviour you consider "strange". The only way to do that disabling for your applications only is to derive a new component form TWSocket and use that new component in your applications. Everything else will still use the original component and work as expected. Clearly here, the "strange method" is not a bug. It is a feature. By design TWSocket reset some properties to default values. There is a good reason behind that design, even if that reason is no more really applicable today, that behaviour must be preserved because existing code may rely on it. 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, either adding a new feature or fixing an issue, and let's discuss it. If it is approved, then your change will be done in the component for everyone. One gold rule with ICS is "do not break existing code unless really really really needed". -- [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
[twsocket] I wan't to stop the server from listening then start it
> You do not need to "redeclare" the properties; all > you need to do is override the AssignDefaultValue() > method, like Francois said. In FTP client, there are two fields of type TWSocket. Whose AssignDefaultValue should I override to stop them from clearing properties? > This method is virtual for precisely this reason. Actually I still can't understand for which reason this method was made > But, in general: yes, that's exactly what you should do. Sorry, but i dont' wish to do all that things just for disabling a single strange method. > Also, keep in mind that you do not necessarily have > to install your custom components into the IDE; you > can very well instantiate any component by calling > it's constructor directly. Of course, you will not > be able to "drop" the component on a form, but > sometimes this is not a big deal. They are components, right? Components are intended to be inited in design-time. As for me, I create ICS objects in run-time, but in general inheritance of visual components is very, very unuseful. > As you wish. But, in my opinion, this is a slippery > slope which ends up in trouble eventually. One of > the worse potential problems with this tactic, which > 've seen before, is that it leads to developers > delaying or avoiding future ICS (or any thrid-party > library) improvements, revisions, and sometimes > important bug-fixes because of the overwhelming > thought of having to track down all possible > modifications and figure out how to merge them back > into the code-base; which ones have been obsoleted by > the update; and which new ones will be needed. Thank you, I'll consider it! -- Regards, Anton -- 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] I wan't to stop the server from listening then start it
>> The correct way doing such behaviour change is to derive your own class >> fromTWSocket and override AssignDefaultValue procedure. This is a nice >> exampleabout what OOP is for. > > It could be nice when using only non-visual TWSocket. Otherwise we receive > additional troubles: derive our own component; install it into IDE. And > what if we have to use other class, for example, ftp client? What we > should do in this case? Derive our new ftp client class, redeclare > Controlsocket and Datasocket properties? No, thanks... I'd better put > several // in the code and will be happy )) You don't need to change the FTP component or any other else. It takes care of everything. You should only change TWSocket because you don't want to do the initi in your application. There is no problem to install you derived component in any package. Personnaly, I always have a package for all components used into an application. A package specific to that application. I never use the packages provided by the component editor (being mine or any other one). I find this much easier to know what exactly an application needs and move the development on another computer. This also help avoiding to have tons of installed components when you don't need them. The only drawback, which is also an advantage in clarity, is that you have to reinstall the right package when you switch from one application to another one. And in my case, this is very easy since the package is always the first in the project group. This has been proven very effective for years now. Note that I understand that each one has difference preferences for his development environment. I only explain how I work. -- [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
Re: [twsocket] I wan't to stop the server from listening then start it
QUOTE: It could be nice when using only non-visual TWSocket. Otherwise we receive additional troubles: derive our own component; install it into IDE. And what if we have to use other class, for example, ftp client? What we should do in this case? Derive our new ftp client class, redeclare Controlsocket and Datasocket properties? You do not need to "redeclare" the properties; all you need to do is override the AssignDefaultValue() method, like Francois said. This method is virtual for precisely this reason. But, in general: yes, that's exactly what you should do. That is the essence of Delphi and Object Oriented Programming (OOP) in general. This separates functionally the underlying ICS classes from your specific implementation and needs, which means that if anything in ICS changes in the future, you most likely only have to update the TWSocket libraries and not have to worry about merging your changes back in, which is time consuming and error prone. Likewise, if you need to add new functionality or update your own implementation, you do not need to worry about ICS at all. This avoids potential conflicts, saves maintenance time, and streamlines development. Also, keep in mind that you do not necessarily have to install your custom components into the IDE; you can very well instantiate any component by calling it's constructor directly. Of course, you will not be able to "drop" the component on a form, but sometimes this is not a big deal. QUOTE: No, thanks... I'd better put several // in the code and will be happy )) As you wish. But, in my opinion, this is a slippery slope which ends up in trouble eventually. One of the worse potential problems with this tactic, which I've seen before, is that it leads to developers delaying or avoiding future ICS (or any thrid-party library) improvements, revisions, and sometimes important bug-fixes because of the overwhelming thought of having to track down all possible modifications and figure out how to merge them back into the code-base; which ones have been obsoleted by the update; and which new ones will be needed. -dZ. -- 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] I wan't to stop the server from listening then start it
> IMO, this will even be worse. When you'll use the next update, you'll be > introuble whatever change you've done in the source. No troubles, I add my signature in comments to track what I've changed in source, and use WinDiff to inject your improvements. > The correct way doing such behaviour change is to derive your own class > fromTWSocket and override AssignDefaultValue procedure. This is a nice > exampleabout what OOP is for. It could be nice when using only non-visual TWSocket. Otherwise we receive additional troubles: derive our own component; install it into IDE. And what if we have to use other class, for example, ftp client? What we should do in this case? Derive our new ftp client class, redeclare Controlsocket and Datasocket properties? No, thanks... I'd better put several // in the code and will be happy )) -- Regards, Anton -- 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] I wan't to stop the server from listening then start it
> Port, protocol, proxy fields of Socket are cleared on Close. > Really embarassing and hard-to-discover feature. > For my projects, I've commented some corresponding lines in ISC source IMO, this will even be worse. When you'll use the next update, you'll be in trouble whatever change you've done in the source. The correct way doing such behaviour change is to derive your own class from TWSocket and override AssignDefaultValue procedure. This is a nice example about what OOP is for. -- [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
[twsocket] I wan't to stop the server from listening then start it
Port, protocol, proxy fields of Socket are cleared on Close. Really embarassing and hard-to-discover feature. For my projects, I've commented some corresponding lines in ISC source -- Regards, Anton -- 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] I wan't to stop the server from listening then start it
Sease, Darin E. wrote: > Hi. > > TSrvForm = class(TForm) > SrvSocket: TWSocket; > ... > > Why does this code work: > > SrvSocket.Close; > SrvSocket.Addr := '0.0.0.0'; > SrvSocket.Port := PortEdit.Text; > SrvSocket.Proto := 'tcp'; > SrvSocket.Listen; > > SrvSocket.Close; > SrvSocket.Addr := '0.0.0.0'; > SrvSocket.Port := 'telnet'; > SrvSocket.Proto := 'tcp'; > SrvSocket.Listen; > > But not this: > > SrvSocket.Close; > SrvSocket.Addr := '0.0.0.0'; > SrvSocket.Port := 'telnet'; > SrvSocket.Proto := 'tcp'; > SrvSocket.Listen; > > SrvSocket.Close; > SrvSocket.Listen; // Invalid argument (#10022 in listen: Port not > assigned) > > Port not assigned? > What is going on? That is 'as designed', you have to (re)set some basic properties before the call to Listen. -- Arno Garrels > > > Darin Sease > Building Systems Analyst > Syracuse City School District > PH: 315 435 4292 > E: [EMAIL PROTECTED] -- 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] I wan't to stop the server from listening then start it
Hi. TSrvForm = class(TForm) SrvSocket: TWSocket; ... Why does this code work: SrvSocket.Close; SrvSocket.Addr := '0.0.0.0'; SrvSocket.Port := PortEdit.Text; SrvSocket.Proto := 'tcp'; SrvSocket.Listen; SrvSocket.Close; SrvSocket.Addr := '0.0.0.0'; SrvSocket.Port := 'telnet'; SrvSocket.Proto := 'tcp'; SrvSocket.Listen; But not this: SrvSocket.Close; SrvSocket.Addr := '0.0.0.0'; SrvSocket.Port := 'telnet'; SrvSocket.Proto := 'tcp'; SrvSocket.Listen; SrvSocket.Close; SrvSocket.Listen; // Invalid argument (#10022 in listen: Port not assigned) Port not assigned? What is going on? Darin Sease Building Systems Analyst Syracuse City School District PH: 315 435 4292 E: [EMAIL PROTECTED] -- 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
