Serialisation change

[Plamen Neykov]

Hi all,

I'd like to commit a small change to the serialisation code in  
QuantLibAddin. It will remove the dependency of the serialised objects  
to the order in which the ValueObjects are registered in the code so  
that additions of new classes or removal of old ones will not break  
the compatibility of existing xml archives. How this works is very  
simple - a class id gets generated only when this class appears in the  
archive for the very first time. This ensures that id's are local to  
the archive and are only dependant on the classes serialised in this  
archive.

The down side is that this will break all existing exports - however  
those exports are anyway not very stable because chances are that they  
get broken with any new class being added in QLA.

Please let me know what you guys think...

cheers,
Plamen





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando M. Ametrano-3]

Hi Plamen

> I'd like to commit a small change to the serialisation code in
> QuantLibAddin.

glad to see you back in action !

> It will remove the dependency of the serialised objects
> to the order in which the ValueObjects are registered in the code so
> that additions of new classes or removal of old ones will not break
> the compatibility of existing xml archives.

this would be a GREAT improvement.

> The down side is that this will break all existing exports - however
> those exports are anyway not very stable because chances are that they
> get broken with any new class being added in QLA.

this is not an issue in my book, since as you said existing archives
are not stable anyway

> How this works is very
> simple - a class id gets generated only when this class appears in the
> archive for the very first time. This ensures that id's are local to
> the archive and are only dependant on the classes serialised in this
> archive.

please help me to better understand what kind of compatibility we
would achieve, and what remaining dependencies we would have to deal
with.
I do understand that as active developer I would gain archive
compatibility between different build of the QLXL addin when exporting
/removing classes, at least when using the same compiler and Boost
Serialization library
Would archives be also compatible across different compilers using the
same Boost? (this might be already true)
Across different Boost libs? (this is probably not true)
Across different QLXL releases? (I'm not sure if other exogenous
elements might compromise compatibility)

Depending on your answer I'm willing to consider this as relevant (or
even mandatory :-) for the QLXL 1.0 release

ciao -- Nando

PS any chance you might also add support these 2 relevant features:
1) coercion from string of comma separated numbers to vector<Quote>,
equivalent to the one available for vector<Real>
2) returning valarray<type> as alternative to vector<type>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev