was `softypename::Symbol` a bad idea?

[dehann]

Just keep it as a softtype in both DFGVariable and DFGVariableSummary?

[dehann]

FYI @GearsAD , I responded here and updated regarding your earlier comment:
https://github.com/JuliaRobotics/DistributedFactorGraphs.jl/wiki/Standard-Definitions-of-API-via-verbs-and-set-theory

[Affie]

Can you elaborate why it was a bad idea?

#199 will give a type to DFGVariable but how will we handle DFGVariableSummary.

How does softtype fit in with possible future use of types such as quaternion on manifold.

[dehann]

Depends on what the user wants to do, if the purpose of DFGVariableSummary is just tell you, hey this is Pose2 but doesn't tell you what it is -- okay. If you need all the manifold information then ... you will need to have a definition of Pose2 to deserialize -- that means get the DataLevel2, DFGVariable (wo/ bigdata).

@Affie , perhaps we can scope what Summary is supposed to do?

[Affie]

One use case is visualization and plotting without the need to get a lot of unnecessary information, PPE is worthless without a type.
Another would be to search for specific nodes. But we spoke about this already somewhere at length.

[Affie]

What is the replacement? I think we should maybe leave for later