{{Quickfixn}} Passing data from SocketReader to Parser
Mike Gatny
mgatny at connamara.com
Wed Nov 5 06:54:58 PST 2014
Staffan,
We welcome all patches -- contribution guidelines are here:
https://github.com/connamara/quickfixn/wiki/Contributor-FAQ
Pull requests are definitely preferred (and there's at least one github
issue filed for this problem already).
Regarding the multi-byte character issue, we'd definitely like to solve
that problem once and for all. From a FIX specification standpoint,
non-ascii encoding is only allowed in certain special "Encoded" fields. In
reality, many major FIX counterparties violate this. Further confusing
that point is the fact that quickfix/j (possibly entirely by coincidence
since java Strings are UTF-16) works fine with non-ascii encodings. So, I
think quickfix/n is in a similar position that web browsers found
themselves in: there is a standard, but there may actually be more people
violating it than actually conforming to it. The web browser solution to
this is to operate in "standards mode" or "quirks mode" as needed, and that
is probably not a bad way to go about it. I.e. it's a bit too late to
insist that everyone encode FIX as ascii per the standard.
If you don't mind re-working your patch as a github pull request, we can
move the review/discussion of it there. Thanks!
Regarding your comments on places where refactoring is needed or
performance could be tuned, you are certainly correct. We've gotten QF/n
to the point where it is a nearly complete port of QF/j and QF/c++, but we
have not yet gone back and done any major refactoring or performance
profiling. Any help in that area would be greatly appreciated -- there
should be plenty of low-hanging fruit!
Thanks,
--
Mike Gatny
Connamara Systems, LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20141105/45927f9a/attachment.htm>
More information about the Quickfixn
mailing list