Folks, Your help is needed. Some documentation on the API between your custom code and the TickZOOM engine now is on the wiki. Your help is needed in commenting on the names and especially help with naming one of them because one name "Formula" was used for two purposes. FYI: I have been refactoring and renaming stuff to make the API more intuitive and to better separate the custom rules from the engine itself. You can comment directly on the wiki page at the bottom on in comments. http://www.tickzoom.org/wiki/TickZoomApi NOTE: The admin is working on moving the navigation bar to the left side. Just ignore the weird layout for now, please. Sincerely, Wayne
TickZoom so far only collects data from the same broker as for the trading. So it's only MB and uses MB quotes. I have mine running on a server 24/7 and collects so it also provides back fill data whenever the black box server needs to connect to run. Several have asked about a backup data source like Zenfire or eSignal. But why do we need that if the broker signal goes down temporarily, we can't trade anyway, right? Oh, but I guess the backup could avoid any gaps on the chart so when it reconnects the system already knows what's going to quickly sideline or not. Thoughts? Wayne
Again, everyone, please visit the http://www.tickzoom.org/wiki/TickZoomApi and share your thoughts. The best way is to register and add your thoughts right on the wiki. Wayne
Well, you're right on avoiding gaps on the charts but most importantly those of us using Zen are interested in fast unfiltered data! I think only Zen provides that? So I use Zen to place orders to any of my 5 brokers and don't even know what their quote is at the time I place the orders! Your API is built around speed and Tick data so filtered tick is not tick data anymore although mind you filtered tick could be faster in busy periods. Anyhow since the API is open source and in C# we should then be able to easily tweak it to accept any feed I guess or not? If not, it would be very helpful to provide provisions to make it easy for the API to ignore it's internal data source and alternatively accept data from some sort of Global memory! Like as in even the TS GV can be used to send it data etc. Anyhow without any knowledge of the source I cannot recommend anything useful yet.
Hi I think the best way to handle all the different providers could be done by presenting an interface. This way it should be fairly easy to program the provider class. If a provider by any reason changes the way they push/pull data, the user of TickZoom only needs to download/ develop the provider class, instead of waiting for a TickZoom patch/ update. I know RightEdge handles it that way
I can't login to your wiki so I'm posting here. Backward compatibility can be a real albatross as the code grows. Maybe you could ensure backward compatibility by supporting all versions. If something is done to break the backward compatability the user can use the older versions until they fix their code to be newly compatible. Interactive Brokers does not do backward compatibility, they break things with their new releases of the API. I guess they work with the main vendors that are using it, not sure about that..
NOTE: This might be only for techies. Currently, the TickZOOM engine gets fed ticks via the TickQueue. The TickQueue a very high speed multithreaded queue. In other words, more than one thread can feed to it at the same time. Right now, I have a BrokerSignalProxy and BrokerSignalStub class which connect via TCP/IP socket between the execution/quote server and the order server (or the PC if you're running under the GUI). So it will be very easy to feed more ticks into the tickEngine. We can add a value into the tick to identify feed source. Just a number (ushort). So if you have 2 tick sources, one can just leave that field the default of zero. The other can give the field a value of 1. That way the engine can differentiate. Now, here's the real question, what's the algorithm for the TickZOOM engine to decide which of those 2 feeds to use? NOTE: We could eventually make the historical tester also able to load and feed 2 files for testing purposes. My guess is that the software assume a backup in order of the number. So as long as ticks feed through 0 fine, it uses those. But if those pause and starts using ticks from the backup till ticks startup again from the primary. Thoughts? Sincerely, Wayne
True. And that is already possible right now and how it works. See my previous post about the TickQueue. In FACT, instead of building that into the engine. Another might put a component called an "aggregator" in front of the engine. The aggregator can do the logic I just talked about of deciding when to switch feeds and then only send a single tick source through to the engine. NOTE: I recommend doing this on a symbol by symbol basis. In other words, the feed might be working for symbol A from provider 0 but failing from symbol B. So the aggregator should switch over to provider 1 for symbol B only as long as it still receives for symbol A. Anyway, it will be possible for someone else to create an aggregator. That logic isn't too complicated and I can help will a little pseudocode probably. In fact, that may be the best design overall to separate that from the engine. But then again, performance will be lost by going through the TickQueue twice due to the thread locking. So someone should add this logic into the "kernel". That's what I call the central core which loops on reading ticks, creating bars, and signaling formulas to take action. Remember, TickZOOM has has to do a number of things that go agains standard OO or component architecture for speed. Certain things like virtual methods, delegates, can KILL performance DEAD if used in the wrong spot of code. Your aggregator will easily become a bottle neck. Wayne Wayne