{{Quickfixn}} Feature Suggestions

Wed Oct 16 11:45:04 PDT 2013

Hi there,

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.

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.

I remind everyone on this list that this is an open source project, and
although feature requests are encouraged, contributions are even more
prized.

Chris.

On Wed, Oct 16, 2013 at 6: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
>
>

-- 
Chris Busbey
Connamara Systems, LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20131016/e4acfebf/attachment-0002.htm>