You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, FactorDFG is a concrete type, that makes serialization and multilanguage support easy.
FactorDFG exists purely for serialization and multilanguage support.
Ideally the packed observation should be [de]serialized directly to JSON and not include the extra string step with manual type creation. This complicates serialization but may be easier in JSON.jl v1
Also decide if observation is a type parameter or abstract type in FactorDFG -- looks like we don't want it as a JSON string any more. Other language SDKs and serialization will likely influence this.
We get closer to dropping the difference between FactorDFG and FactorCompute if we go with type parameter.
We may want to be able to use the observation independent from the factor, ie. getObservation, if true, <: Observations will likely need a type field in the JSON string and not only depend on the factor type. xref Restore for variables and factors the module prefix #1140 (comment)
We can/should consolidate FactorDFG and FactroCompute (as FactorDFG)
Notes:
FactorDFGis a concrete type, that makes serialization and multilanguage support easy.FactorDFGexists purely for serialization and multilanguage support.FactorDFGandFactorComputeif we go with type parameter.getObservation, if true,<: Observations will likely need a type field in the JSON string and not only depend on the factor type. xref Restore for variables and factors the module prefix #1140 (comment)FactorDFGandFactroCompute(asFactorDFG)