{{Quickfixn}} Feature Suggestions

Wed Oct 16 12:03:21 PDT 2013

1. I haven't noticed this myself, but you're probably correct.  Wanna work
on a fix?

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.

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.

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.

5. I'm actively working on integrating that SSL fix.

On Wed, Oct 16, 2013 at 11:36 AM, Phillip Wei
<pwei at bluemountaincapital.com>wrote:

>  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
>
>

-- 
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/fa4f2305/attachment-0002.htm>