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
>> 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 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.
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