{{Quickfixn}} Passing data from SocketReader to Parser

[Grant Birchmeier]

Me and Mike were talking a little yesterday about this and also broader
QF/n issues.

There's a lot of things in the code that are just not very awesome.  Such
as:

   - Overcomplex code
   - Unnecessary duplication
   - Crazy code flow between Session and Initiator/Acceptor
   - Lots of un-C#-like things (get/set functions instead of properties,
   lower-cased functions)
   - Many public things that should not be public
   - Terrible logging

I'm starting to wonder if it's time for a 2.0.  The need for backward
compatibility is starting to feel like a straightjacket, and our velocity
is zero.  It'd be refreshing if we could be a little reckless for a while.



On Wed, Nov 5, 2014 at 8:54 AM, Mike Gatny <mgatny at connamara.com> wrote:

> 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
>
>
> _______________________________________________
> 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/20141105/be191636/attachment.htm>