<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1975090551;
mso-list-type:hybrid;
mso-list-template-ids:-1767589288 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Happy to work on implementing these things. We just wanted to first understand where the QuickFIX/n community stood. Diverting from what everyone else is doing would make uptaking future changes much more challenging, so we wanted to reach out first, make sure these were real issues others would be open to pulling in.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Has anyone else noticed this? I’m using VS2010 w/ Resharper 8.0.1. It was pretty difficult to do any coding without intellisense, and so the first thing I did was hack a fix – but I’m itching to just put this into the generator. It would be odd to me if people were having this problem and not noticing it. Maybe I’m doing something wrong?<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Improving the resilience of the generators is probably not outside the original architecture, but having customizations exist as XML partials definitely is (so maybe we avoid doing that part). Though, it seems possible to do this in a way that maintains backwards compatbility if XML partials exist seperate (subfolder) and as an input to the generation process, and the generation process is responsible for merging. That way things stay the same if you don’t do additional customization. I’ll have to think through this.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’m actually quite fond of Ruby but think it’s awkward to have a .NET port that then requires additional languages. I don’t have experience with T4, but I’ll give it a try.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>4.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think it’s as simple as passing in the DefaultApplVerID, though, I don’t know if it’s really ok to break the IMessageFactory interface for people who are implementing custom MessageFactories (is anyone doing this?). It’s also nice to keep the list of changes for QuickFIX .NET wrapper migrators short. This interface comes from QuickFIX. I’m curious ... does anyone know if this is also broken in QuickFix/QuickFixJ? If it’s not broken there, it would suggest there is probably something fundamentally wrong that needs to be fixed in QuickFIXn – but if not, freeing the interface to do the right thing seems like the only option.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>5.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Great! I checked out David Svensson’s work and it seemed to work well. But the downsides of not pulling from master outweighed the benefits, so I skipped it at the time. We’re looking forward to this.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Phil<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> quickfixn-bounces@lists.quickfixn.com [mailto:quickfixn-bounces@lists.quickfixn.com] <b>On Behalf Of </b>Grant Birchmeier<br><b>Sent:</b> Wednesday, October 16, 2013 3:03 PM<br><b>To:</b> Mailing list for QuickFIX/n<br><b>Subject:</b> Re: {{Quickfixn}} Feature Suggestions<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><span style='color:black'>1. I haven't noticed this myself, but you're probably correct. Wanna work on a fix?<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>2. If I understand you right, this isn't just a problem with QF/n, but with all QuickFIX ports. It's kind of a problem inherent in the architecture of the engine. I'm not sure how one would elegantly implement the things that you're suggesting. If it's something you'd like to see, please take a stab at implementing it.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>3. We used Ruby because it's what the project creators knew best at the time. We haven't changed it because it's not broken, and thus not a priority for our development time. If someone would like to pay us to make this a priority, I'm sure we can make an arrangement. Or, this being open source, one of you can work on a code contribution. Lots of you apparently hate Ruby, but no one hates it enough to work on an alternative.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>4. Yes, I know. The FIX5 stuff needs some love, and I cannot honestly say it's production-ready. I was planning to give it a look after I finish the SSL stuff.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>5. I'm actively working on integrating that SSL fix.<o:p></o:p></span></p></div></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Wed, Oct 16, 2013 at 11:36 AM, Phillip Wei <<a href="mailto:pwei@bluemountaincapital.com" target="_blank">pwei@bluemountaincapital.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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).<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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).<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>5. SSL. Seems like a known and common request. I see an outstanding pull request.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Interested in hearing what other people’s views are on these matters.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Phil<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=2 width="100%" align=center></div><p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif";color:black'>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><o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><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><o:p></o:p></p></div><p class=MsoNormal><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><p class=MsoNormal><span style='background:white'>Grant Birchmeier</span><o:p></o:p></p></div><div><p class=MsoNormal><b><span style='color:#3333FF;background:#FFCC00'>Connamara Systems, LLC</span></b><o:p></o:p></p></div><div><p class=MsoNormal><b>Made-To-Measure Trading Solutions.</b><o:p></o:p></p></div><div><p class=MsoNormal>Exactly what you need. No more. No less.<o:p></o:p></p></div><div><p class=MsoNormal><a href="http://connamara.com" target="_blank">http://connamara.com</a><o:p></o:p></p></div></div></div></body></html>