{{Quickfixn}} Feature Suggestions

Wed Oct 16 11:42:48 PDT 2013

"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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20131016/5aab8671/attachment-0002.htm>