Daniel Rail wrote:

>I like the idea. Also, how about having the possibility to add 3rd
>party protocols? This would help some users to develop their own
>protocol, if they wish to have a more secure connection according to
>their specs.
>

Part and parcel. The order of battle goes like this:

1. The Y-valve uses the given database name to find a <database ...>
object
2. The Y-valve loops through the privider names given in the database
"provider" option
3. For named provider, in order, the Y-valve looks for a <provider
...> object
4. For each provider object the Y-valve looks for a "library" option
5. If the Y-valve can load the provider library and find a the symbol
"getSubsystems" it calls getSubsystems, which returns a vector of
"Subsystem" objects, terminated with a null pointer
6. The Y-valve then invokes the method Subsystem::attachDatabase()
with the user supplied args and the provider name to see if the
provide can handle the attachment. If successful, the Y-valves
wraps the subsystem object and handle at returns to the user.

The process is completely open. Nothing is called that is not present
in the configuration files. The provider interface is architecturally
controlled by the class Subsystem (provider subsystems inherit from
it). This means that somebody could develop an SSL based protocol and
just plug it in.

This is only half the equation, however. We should also design a
corresponding mechanism to configure servers so a server
formerly-know-as-superserver handle connections from an arbitrary
collection of protocol handlers.

But first I have to cleanup CVT/Move can I can build a remote client
without an unreasonable amount of crud.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376



[Non-text portions of this message have been removed]