Subject | Remote Providers |
---|---|
Author | Jim Starkey |
Post date | 2004-02-09T23:32:37Z |
Since around the beginning of time, remote has been a single provider --
it is called once by the Y-valve and cycles through all known
communication subsystems. Once upon a time this was a clean solution.
'Tain't necessarily so now.
I think it would make a great more sense to configure each remote
connection type as separate providers each each can have separate
configuration parameters. This would allow, for example, to have
multiple tcp providers with different ports for either different
database or included in a single list of providers to be polled, one by
one, in the order specified. It would also mean that an administrator
could restrict the protocols available by dropping the unwanted from the
list of providers for the fallback database definition.
Describing it makes it seem like a no-brainer...
Thoughts?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
it is called once by the Y-valve and cycles through all known
communication subsystems. Once upon a time this was a clean solution.
'Tain't necessarily so now.
I think it would make a great more sense to configure each remote
connection type as separate providers each each can have separate
configuration parameters. This would allow, for example, to have
multiple tcp providers with different ports for either different
database or included in a single list of providers to be polled, one by
one, in the order specified. It would also mean that an administrator
could restrict the protocols available by dropping the unwanted from the
list of providers for the fallback database definition.
Describing it makes it seem like a no-brainer...
Thoughts?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376