> Ultimately, this path (or something like it) will be necessary to prevent
> terminal forking of the project. I've noted that most of the differing
> requirements are popping up with the management tools (and not with the
Yes, this is true.
> It's better for me not to have to maintain different versions of
> cipsrvr and cipdrvr all over the place.
I did not make any change to the driver; it is still the original
2.0.pre-15 version. As far as cipsrvr is concerned, I have added only
some functions to generate the routing commands and to deal with the
optional key encryption. If key encryption is not enabled, cipsrvr
behaves identical to the original 2.0.pre-15 version. I will double
check this and make sure that the old and the new version of the panel
are compatible on the binary level (if compiled against the same peer
class) and that the cipsrvr version I made works with both of them. This
will provide a certain flexibility of the user interface, although
probably less elegant than the management console which I understood you
will soon start to code. At least until then, we could support the two
panels - would this be too hard to do?