Re: QL FpML Object Handler Modifications

Posted by Fabrice Carrega on
URL: http://quantlib.414.s1.nabble.com/QL-FpML-Object-Handler-Modifications-tp10749p10751.html

Hello there,


I have started reading FpML specs (which is not the best book I have
ever read, I must admit), and will need some more time to finish.

Concerning my participation, I am still interested in coding part of
the new QuantLib-FpML module, as described by Eric in his last post.

I was also thinking of contacting one of the FpML development groups
to ask them what will be the next steps in the development of this
language.


Bonne soirée,

Fabrice


On Mon, 28 Feb 2005 12:35:03 +0000, eric ehlers <[hidden email]> wrote:

> Hi David
>
> Welcome back, glad to hear that your negotiations are progressing, and
> looking forward to your project getting underway.
>
> >    After discussing with out Professor the idea of assisting with
> > GNUmeric implementation to QuantLibAddIn we found that our project was
> > not suitable.
>
> I know you mentioned a Gnumeric plugin, I hadn't understood that you
> were considering that for your project.
>
> > He said that wrappers were not a good substitute for a
> > complete learning experience involving object oriented programming.
>
> I agree.  Wrapping QuantLibAddin for any specific platform is a small
> technical exercise, mainly writing a Python script to autogenerate the
> source for the Addin.
>
> >    Eric:  We are not clear on whether you would be implementing FpML
> > if we built a modified object handler subclass that encoded /
> > unencoded FpML (or as Luigi called it:  Serialized / Deserialized
> > FpML.)  We are simply asking to make sure that no one is peforming
> > redundant work.
>
> I don't think there will be a subclass of ObjectHandler, nor any
> functionality in ObjectHandler for directly (De)Serializing FpML.
>
> Irrespective of who does what, let me first reiterate my current
> understanding of what needs to be done:
>
> In QuantLib:
> - implementation of TermSheet classes
> - extension of Instrument classes to support new constructors
> accepting TermSheet as input
>
> In new component QuantLib-FpML:
> - translation of FpML <-> TermSheet
>
> (note that QuantLib is now FpML-enabled - independent of
> ObjectHandler/QuantLibAddin)
>
> In ObjectHandler:
> - extend the abstract base class Object to include (De)Serialize
> member functions (which would be pure virtual)
> - extend class ObjectHandler to support (Un)Load functions (which in
> turn invoke Object->(De)Serialize).
>
> In QuantLibAddin:
> - for derived Object classes - override (De)Serialize to call the code
> in QuantLib-FpML appropriate for the underlying QuantLib object
>
> Back to the question of avoiding redundant work - I definitely agree
> that we need to clarify who does what - I haven't yet started to think
> about what I'd do personally and it depends a lot on what you would
> enjoy doing.
>
> >    Luigi:  Could you send us some links on the current structure of
> > the QL_Object_Handler that woudl require modification?  Any advice is
> > appreciated.
>
> Hopefully the comments above clarify the changes required in
> ObjectHandler?  There isn't much, with the main FpML-specific
> functionality implemented in QuantLib-FpML.
>
> Hope this clarifies things.  Very much looking forward to hearing your
> project proposal, please let me know what I can do to help.
>
> Best Regards,
> Eric
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Quantlib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>