{{Quickfixn}} Feature Suggestions

Wed Oct 16 11:22:45 PDT 2013

I agree and I have pointed out this issue regarding code generation before.
The reason, given, why T4 is not used was that not everyone uses Visual
Studio, which I, however, find a pretty weak argument given what can be
gained without the unnecessary Ruby+Nokogiri load. I find it hard to
imagine that anyone running a FIX engine in Linux would consider QuickFIX/n
in the first place, making the argument that some use different C# code
editors kind of obsolete.

Matt

On Thu, Oct 17, 2013 at 1:41 AM, Thomas Tomiczek
<t.tomiczek at nettecture.com>wrote:

>  Exactly.****
>
> ** **
>
> To add, Ruby is totally unneeded. T4 code generation is in visual studio
> for ages and can do what is currently done a LOT faster.****
>
> ** **
>
> *From:* quickfixn-bounces at lists.quickfixn.com [mailto:
> quickfixn-bounces at lists.quickfixn.com] *On Behalf Of *Phillip Wei
> *Sent:* 16 October 2013 18:36
> *To:* quickfixn at lists.quickfixn.com
> *Subject:* {{Quickfixn}} Feature Suggestions****
>
> ** **
>
> Hi,****
>
> ** **
>
> We’ve begun testing QuickFIX/n here at BlueMountain Capital and have run
> into a few issues.  We are wondering if these are pain points for other
> people too.  We’re more than happy to lead these changes, but not if it
> forks us significantly away from what others are doing (or, of course, if
> we’ve misunderstood the issue).****
>
> ** **
>
> 1. The way the FixMessage project is included breaks intellisense.  The
> generator writes to FixMessag.proj, which is included in QuickFix.proj via
> a project import statement.  Doing it this way allows for a simpler logic
> in proj_gen.rb (and things will compile) but autosuggest doesn’t work.
> That’s unfortunate, since that’s one of the biggest appeals of having the
> generate classes specify fields explicitly.  If proj_gen.rb modified the
> QuickFix.proj directly, this problem could be avoided.****
>
> ** **
>
> 2. Customizing isn’t a one-touch process.  When customizing you not only
> want to add additional fields, you’ll also (usually) want to ensure some of
> those fields are required.  However, if you’re handling multiple parties,
> you can’t just add your changes in the existing XML files.  Customizations
> between parties will collide; what is required for one party certainly
> won’t be even known by the other.  So you create seperate XML files for
> each party.  But messages_gen.rb is hard coded against specific XML files,
> so each new XML file requires modifications to successfully run.  Then, to
> generate the new messages, you re-run the generator.  I appreciate this
> isn’t a problem unless you have multiple endpoints you are targeting and
> that smoother regeneration isn’t a priority if you aren’t doing it often.
> But once you are customizing against many parties it’s easy to for this to
> become frustrating.****
>
> ** **
>
> I think the generators could be modified to attempt to do something more
> intelligent (infer the underlying FIX protocol from the XML file name).  It
> also seems that since customizations are always layered on top of an
> existant protocol, having to fully respecify the protocol in each custom
> XML file is unnecessary (and hard to read).  Defining customizations as
> extensions to the base FIX XML files could be a simpler way to manage
> changes (think of customizations as XML partials that are merged).  I also
> think it’s smoother to have the message generation run as a project Build
> Event.  That way, all changes and updates can be managed within Visual
> Studio.****
>
> ** **
>
> 3. Ruby & nokogiri as additional dependencies.  Though it’s quite easy to
> setup, I don’t think there should be additional language dependencies.  All
> our developers are familiar with .NET, and all our system builds include
> Visual Studio.  QuickFIX/n being in .NET was a big reason we decided to try
> it out.  Installing and running Ruby is something any developer should
> easily be able to do – but it’s a roadbump that slows things down if you
> don’t already have it on your system.  If there is a strong and compelling
> reason to be using Ruby, I’d be interested to hear it – but to me it seems
> like the generator code could just as easily be in C#.  It would be
> straight forward to test too (just compare with Ruby output).****
>
> ** **
>
> 4. FIX 5.0 SP1/SP2 handling.  The DefaultMessageFactory always hardcodes
> FIXT11 messages to FIX50 and so it doesn’t support SP1, SP2 – or older
> versions running either.  As the FIXME comment indicates, it’s a known
> issue.  IMessageFactory.Create is only ever called from the
> DefaultMessageFactory itself, or in Session.cs.  The Session knows the
> DefaultApplVerID – either the one it’s expecting (SenderDefaultApplVerId)
> or the one it got (targetDefaultApplVerID), so if the interface was just
> extended to take this value in, it could correctly determine the right
> factory to use.  Since this is a public interface, I realize it’s a
> breaking change, so that may be why it hasn’t been updated – but, on the
> other hand, FIXT11 basically doesn’t work at the moment.****
>
> ** **
>
> 5. SSL.  Seems like a known and common request. I see an outstanding pull
> request.****
>
> ** **
>
> Interested in hearing what other people’s views are on these matters.****
>
> ** **
>
> Phil****
>
> ** **
>  ------------------------------
>
> This e-mail is intended only for the person or entity to which it is
> addressed and may contain confidential and/or privileged material. Any
> review, retransmission, dissemination or other use of, or taking of any
> action in reliance upon, the information in this e-mail by persons or
> entities other than the intended recipient is prohibited and may be
> unlawful. If you received this in error, please contact the sender and
> delete the material from any computer.
>
> This communication is for informational purposes only. It is not intended
> as and does not constitute an offer or solicitation for the purchase or
> sale of any financial instrument or as an official confirmation of any
> transaction. All market prices, data and other information are not
> warranted as to completeness or accuracy and are subject to change without
> notice. Any expected returns are provided for illustrative purposes only
> and are not intended to serve as, and must not be relied upon by any
> prospective investor as, a guaranty, an assurance, a prediction of a
> definitive statement of fact or a probability. Investment in funds managed
> by BlueMountain carries certain risks, including the risk of loss of
> principal. Unless indicated otherwise, performance results are presented
> net of fees and expenses. Certain market and economic events having an
> impact on performance may not repeat themselves. Any comments or statements
> made herein do not necessarily reflect those of BlueMountain Capital
> Management, LLC or its affiliates. PAST RESULTS ARE NOT NECESSARILY
> INDICATIVE OF FUTURE RESULTS AND NO REPRESENTATION IS MADE THAT RESULTS
> SIMILAR TO THOSE SHOWN CAN BE ACHIEVED.****
>
> _______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20131017/26ab3b17/attachment-0002.htm>