{{Quickfixn}} Feature Suggestions

Wed Oct 16 11:55:27 PDT 2013

I think that is the reason you gave me when we talked a while ago. Care to
elaborate then why not using T4 which is tightly integrated with VS?

Thanks
Matt

On Thu, Oct 17, 2013 at 3:42 AM, Grant Birchmeier <gbirchmeier at connamara.com
> wrote:

> "The reason, given, why T4 is not used was that not everyone uses Visual
> Studio"
>
> No, this was never a reason.  I don't know where you got that from.  (We
> do have experimental Mono support, but it's not the reason we use Ruby.)
>
>
>
>
> On Wed, Oct 16, 2013 at 1:22 PM, Matthias Wolf <matt.wolf74 at gmail.com>wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> Quickfixn mailing list
>> Quickfixn at lists.quickfixn.com
>> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>>
>>
>
>
> --
> Grant Birchmeier
> *Connamara Systems, LLC*
> *Made-To-Measure Trading Solutions.*
> Exactly what you need. No more. No less.*
> *
> http://connamara.com
>
> _______________________________________________
> 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/1ea6facf/attachment-0002.htm>