[Quickfix-developers] The open approach (was Re: Quickfix for FIX 5.0)

[Graham M. <gm...@ma...>]

Nick,

As long-time users of QuickFIX, we felt we needed to respond, given
that we believe your opinion part of a very small minority.  Your
objections are too vague to be sure, but it seems that your
displeasure with QuickFIX may stem from an impedance mismatch between
what QuickFIX currently aims to deliver and what you need to implement
your trading system.  This is certainly the forum to discuss these
issues.

However, it makes absolutely no sense to us why anyone would drop
QuickFIX entirely, given the size of the FIX specification and the
very permissive license under which QuickFIX is distributed. Do not
like the networking code? Swap in your own.  Need a Delphi API? Add
one. The fact that you have chosen to toss the thousands of hours of
work that have been contributed to the QuickFIX project, so that you
can re-implement it all yourself seems to indicate that you have not
done the cost-benefit analysis very carefully.

The implementation details of sequence reset handling and crashes have
recently garnered a fair amount of traffic on the mailing lists
(perhaps this is why you are so acutely aware of them).  To us this
only shows the strength of the process.  We have no reason to believe
that closed-source commercial implementations like the one you're
proposing have any fewer defects--indeed we have seen a few with many
more defects--and they lack the facility for peer review that we value
in QuickFIX.

We have placed our bets on the open approach, and we do not envy you
the long hard road ahead.

graham
and the Marketcetera team

-- 
Marketcetera Trading Platform
download.run.trade.
www.marketcetera.org

On Oct 25, 2006, at 9:37 AM, Nick Evgeniev wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> don't know about fix 5.0
> quickfix obviously needs architecture changes in it's current state
> it suited well only for fix sandboxes, as it has no explicit
> transaction management, hence it has no batching operations. it has
> brokenly designed synchronization and as a bonus has numerous
> errors in reset sequence handling and unexpected crashes in native
> code in connection handling.
> The last two issues are implementation details, but the first two
> are crucial for high volume transaction processing.
> We'd been evaluating quickfix for about half year, but finally
> decided to drop it in favor of homegrown engine because of issues
> I've written above.
> Just wonder that nowadays, after all the litrechure regarding
> highspeed message parsing available for $30 bucks at amazon, we
> have such brokenly designed product :(
>