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 pascal
syntax) for the developper to iterate thru all subcomponent. An indexed
property has my favor. We should propably think ahead when D7 has no more ot
be supported and provide a design which will easily allow an iteration
implementation to use foreach construct. Methods to add/remove subcomponents
are OK. No problem
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 have all subcomponent event handler created equal to
the main and let the user change it later. Don't know yet what is better.
About Addr/Port:
I agree with you. A new property "MultiListenAddrPort" has to be used and
all instance will get his own value assigned to his Addr and Port
properties.
About persistent properties:
I don't understand the issue.
About general design consideration:
My idea is to create a component which would cover 80% of the needs for
multiple listening sockets. All very special cases could still be handled as
it is today with individual components. Trying to make the new component fit
100% of the needs will result in a too complex component.
--
francois.pie...@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
----- Original Message -----
From: "Arno Garrels" <arno.garr...@gmx.de>
To: "ICS support mailing" <twsocket@elists.org>
Sent: Saturday, November 27, 2010 12:01 PM
Subject: Re: [twsocket] TWSocketServer: how to make
itlisteningtoseveralIP:Port ?
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 keep track of the secondary instances.
Yes, that should be a TComponentList owning the instances.
A new r/o property
"MultiListenList" (and btw "MultiListenListCount") would gives the list
of
all TWSocketServer, in the order specified in the Addr property. All
TWSocketServer share the same list.
MultiListenIndex would be "-1",
MultiListenList would be nil and MultiListenCount would be 0 if
TWSocketServer is used alone. Each get a new property "MultiListenIndex"
which is their index in that list.
At first I would not expose the list but provide public methods to Add and
Delete instances and to access instances by index (r/o). I would simply
fake
the list with count "1" when there are no additional instances and the
list
is not assigned. Listener[0] returned Self, ListenerCount "1" etc..
All clients should be added to main instance's client list, the Sender
argument in server events gives you the server object triggered the event.
I'm not sure whether you have that in mind, have you?
All event handlers are
common to all TWSocketServer instances.
That should be the default assignment after a call to method Add()
only to ease setup of the new instance.
All event assignments and unassignments have to be kept in sync.
They will be easily with setter and getter.
That may work, but it is confusing since one can easily change the
event handlers of additional instances. It was cleaner to not synchronize
event assignments except in method AddServer() to set the defaults.
Also I would not bind the construction/destruction of the additional
instances to the Addr string property (grrr),
Why "grrr" ? Please explain.
At least that should be a new string property since Addr and Port
identify the instance too.
It remains a hack as long as not all relevant persistent properties
are available in Object Inspector. What about SslEnable? It's cleaner
to let users explicitly create additional instances at runtime.
If just a fraction of persistent properties are assigned the component
user has to set the rest at runtime, that's confusing.
--
Arno Garrels
--
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
