| From: Andrew Cagney <andrew.cag...@gmail.com> | - instantiate non-template connections (this idea keeps coming up on IRC)
This is off the top of my head. It might be wrong. And too philosophical. The original idea was that connections were immutable -- all changes were in state objects. It was convenient to add mutable fields to keep track of the states using connections. Arguably that should have been in another datastructure, but it was convenient to jam it in there because there was a one-to-one relationship with this datastructure and a connection. For example: keeping track of the most recent state that was associated with the connection. (State objects are not one-to-one with connections. That's why it was obvious that they should be separate datastructures. But an alternative would be to copy all of the connection object into the state; that copy could be mutated.) Then connections were derived from other ones, with more details filled in. This was instantiation. It could happen for a variety of reasons and with a variety of details added. If the new thing has a one-to-one relationship with the connection, there was a strong temptation to just jam the additional info into a connection. This may or may not be a mistake. I think that's what you are dealing with. I do think that it is wrong to lose something that came from a config file. _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
