Francois PIETTE wrote:
>>> This design would not break any existing code and would ease using
>>> the new multiple listen easy to implement in higher level
>>> components.
>
>> It won't break existing code, but remains a hack IMO.
>
> I don't agree with you. Please explain.
> The main instance
Hi Arno,
After your first message I tough you where lighting years away from my
design. I understand now that we agree on most items.
About the list:
I had not expressed how the list has to be implemented. The requirement is
that the component offer a method (in general sense, not in object p
Francois PIETTE wrote:
> About event handler:
> We have the choice to enforce all are in sync or not. I'm not sure
> yet what is best. At least it is easy to propagate all event handlers
> to all component whichever subcomponent is used to assign the new
> event handler. It is also very easy to ha
There is, for instance, property SslEnable in TWSocketServer descendant
TSslWSocketServer that is propagated to clients.
Let's say you want two listeners /192.168.1.1:80/192.168.1.1:443
one SSL and one plain text. Then you have to set SslEnable
property at run time.
Maybe not. Look at TStatusBar
Francois PIETTE wrote:
>> There is, for instance, property SslEnable in TWSocketServer
>> descendant TSslWSocketServer that is propagated to clients.
>> Let's say you want two listeners /192.168.1.1:80/192.168.1.1:443
>> one SSL and one plain text. Then you have to set SslEnable
>> property at run
A string property is very easy for the component user at runtime. A single
line of code allows to setup all the subcomponents. And this ease
saving/loading the configuration for the application.
As I said before creating/destroying objects on the fly depending on
what the user types in a strin
Francois PIETTE wrote:
> A string property is very easy for the component user at runtime. A
> single line of code allows to setup all the subcomponents. And this
> ease saving/loading the configuration for the application.
>
>> As I said before creating/destroying objects on the fly depending on
So, as I understand the approach the TWSocketServer shall be extended
as a wrapper or helper to make the workaround of creating multiple
TWSocketServer instances in code easier. In this case it _might be
better to create a new component that handles this?
I think most server application can be e
Hello!
>> Now let's assume that application listens on two ip:port pairs, each for
>> different kind of communication. For example, 192.168.1.1:2048 and
>> 192.168.1.1:27015. Also, let's assume that user can define on which
>> ip:port
>> one of servers should listen (another ip:port pair would be
Francois PIETTE wrote:
>> In my option a real ICS multi-listening server should handle all
>> client objects in one list. These client objects should be aware of
>> what listening socket accepted them.
>
> That is a good idea.
>
>> This is not possible to achive
>> with current TWSocketServer des
10 matches
Mail list logo
