<div dir="ltr">Hi there,<div><br></div><div>The reason why ruby was used for generation at project conception was that most of the original developers were more familiar with ruby. This has not been a high priority issue for the core development team because the ruby generation works as advertised. AFAIK, there have been no objections to a port of the generation to something .NET developers may be more comfortable with.</div>
<div><br></div><div>I challenge the community to contribute a pull request to rid QuickFIX/n of ruby. Based on the number of .NET developers that request a move away from ruby, it seems like this should be an easy transition.</div>
<div><br></div><div>I remind everyone on this list that this is an open source project, and although feature requests are encouraged, contributions are even more prized.</div><div><br></div><div>Chris.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 16, 2013 at 6:22 PM, Matthias Wolf <span dir="ltr"><<a href="mailto:matt.wolf74@gmail.com" target="_blank">matt.wolf74@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. <div>
<br></div><div>Matt</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Thu, Oct 17, 2013 at 1:41 AM, Thomas Tomiczek <span dir="ltr"><<a href="mailto:t.tomiczek@nettecture.com" target="_blank">t.tomiczek@nettecture.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="color:#1f497d">Exactly.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> <a href="mailto:quickfixn-bounces@lists.quickfixn.com" target="_blank">quickfixn-bounces@lists.quickfixn.com</a> [mailto:<a href="mailto:quickfixn-bounces@lists.quickfixn.com" target="_blank">quickfixn-bounces@lists.quickfixn.com</a>]
<b>On Behalf Of </b>Phillip Wei<br>
<b>Sent:</b> 16 October 2013 18:36<br>
<b>To:</b> <a href="mailto:quickfixn@lists.quickfixn.com" target="_blank">quickfixn@lists.quickfixn.com</a><br>
<b>Subject:</b> {{Quickfixn}} Feature Suggestions<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="EN-US">Hi,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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).<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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).<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">5. SSL. Seems like a known and common request. I see an outstanding pull request.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Interested in hearing what other people’s views are on these matters.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Phil<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Times New Roman","serif""><u></u> <u></u></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US" style="font-size:12.0pt;font-family:"Times New Roman","serif"">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:7.5pt;font-family:"Arial","sans-serif"">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.<br>
<br>
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.</span><span lang="EN-US" style="font-size:12.0pt;font-family:"Times New Roman","serif""><u></u><u></u></span></p>
</div>
</div>
<br></div></div>_______________________________________________<br>
Quickfixn mailing list<br>
<a href="mailto:Quickfixn@lists.quickfixn.com" target="_blank">Quickfixn@lists.quickfixn.com</a><br>
<a href="http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com" target="_blank">http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
Quickfixn mailing list<br>
<a href="mailto:Quickfixn@lists.quickfixn.com">Quickfixn@lists.quickfixn.com</a><br>
<a href="http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com" target="_blank">http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Chris Busbey<br>Connamara Systems, LLC
</div>