most of this stuff is going to only apply to sdk folks.
"1) I admit it was some time ago when I checked but I am absolutely positive multi-symbol merge historical streams did not exist 2010. I asked about it and discussed it in length, there was working being done but it was unusable and incredibly slow. "
That's about half right. multi symbol was always there but it got huge speed bump in 2009 or perhaps very early 2010. it wasn't called multisym until single sym was added.
"Please can you inform the community of the speed an average platform processes quote/tick data per second on the multi-symbol engine? "
google tradelink speed
"Can you provide couple examples, examples make everything very clear and people can judge for themselves whether it fits their needs before committing tens if not hundreds of hours finding out later it may not suit their needs. "
google tradelink project or tradelink quickstart
2) "you can EASILY merge the two"? Come on, please let's be a little more truthful here.
Based on your comments I can tell you are an experienced and accomplished developer. from a programming point of view, Tradelink makes that easy. more below.
the harder part is usually the community part. massaging the community to get the help you need, but also learning from when you don't get a response.
also I certainly don't claim we know how to do the community part right, it's hard. if you're a pure open source user, we always encourage people to start discussions and get involved. don't depend on the "primary guys" to do anything other than their best to ensure your contributions don't break others contributions.
"I find it quite irresponsible to say a testing platform and a live trading platform with entirely different code bases (yes they do share common interfaces) can be easily merged together. Thats simply not gonna happen EASILY.
If the tradelink SDK was just interfaces I would agree with you. because the SDK kadina and ASP apps are NOT entirely different code bases. merging them into a single app, that is not a difficult project (for people like you that have "the skills" and also the desire).
since many of the biggest contributors including myself came from big hedge funds where we had platforms that supported large varieties of trading applications and strategies... we've always tried to stick to this intention even as the platform has evolved since 2007 (open source since 2008). so we should have something to offer here, but obviously you have to judge for yourself.
3) Anyone can do a simple search on the TradeLink google discussion forum for "FIX". Yes there is a half-developed FIX adapter but its essentially un-finished, unusable. Again I am not criticizing that its not done I am criticizing that when I discussed it and asked questions on the forum the adapter was over-advertised as being usable when it was in fact far from being that.
Ok, except I'm not exactly sure what your criticism is. I think FIX template was added in late 2010. In tradelink we mark our FIX connector as a template, to differentiate it from named connectors that are already turnkey for specific brokers.
I would agree that apart from tradelink.... FIX in general is over-advertised as being a turnkey standard.
4) Ok, mate, with all due respect, if you call the crude windows a GUI then I give that to you, sorry, my apologies, I stand corrected.
But I am talking WPF grade charts.
We would love to have more UI focus. But I think it's unfair to suggest to people we don't have any charts and UI and so forth. We've had charts since 2007, maybe not amazingIndustry-riffic charts but they are quite functional. you can see prices and days and everything and draw on them.
"A GUI in a trading platform is something where you start and stop back tests, where you set ALL parameters, where you receive ALL statistical analysis analytics, "
Again maybe this is a several years ago criticism, but you can actually set all parameters outside of code. Sounds like you could probably do much better GUIs than us.
As I mentioned previously there are 30-40 stats included, and easy export to R/excel for custom no programming stats. Sounds like you could probably snaz this up a lot and maybe make it more intuitive to use. It sounds to me as if you could even do it pretty easily, but what do I know about that.
We'd encourage you to add this stuff in an SDK friendly way, so it can be unbundled and incorporated to as many of the apps and use cases as possible with min effort (and to simplify merges such as you suggest above).
but really even if you don't do this or if a contribution isn't incorporated in the trunk, it will still be used and appreciated and all that gooey warm stuff.
hopefully this was helpful. i probably won't comment too much more here but will try to read the entire stream.
