Hi kvm,

I just wanted to update the Dukascopy plugin, which I'm the author.
In order to provide a good compliance quality, I need to have a specification with as little ambiguaties as possible.
The BrokerBuy2 description raises too many of them.
There is also the issue of BrokerHistory2 for Dukascopy.
This broker sends ticks on a ask and bid basis, which means you can have multiple ticks in a row with the same ask price(but different spreads, vol, etc.)
Here I'm not sure if I have to filter these ticks out of the stream.

Hi ibne,

What a coincidence I'm the author of the Dukascopy plugin (yet another version)

I'm not filtering these ticks. Just returning the last one received.

So we can join forces on trying to undertsand the Zoro API

Not filtering these ticks might look very strange on a tick chart, with periods of a "flat" line.
I guess this defeates the purpose of a "tick", which to me means a price change.

Btw: when you also work with Dukascopy, you will agree that their API is even more broken...

I'll be glad to collaborate with you!

I'm using these ticks coming from Strategy.onTick() method only to return the current price information via brokerAsset() method.

When Zorro calls brokerHistory2() then I'm using History.getTicks() to retrieve them.

In my opinion the Dukascopy API is too complicated but decent. However, the implementation is not the best one. What version do you use?

The latest one:
DDS2-jClient-JForex 3.4.13
JForex-API 2.13.62

Their API is overloaded and not very user friendly.
Take for example the IEngine.executeTask() method.
Why should the user take care on which thread he is when executing order related tasks?
The API could handle this easily...
This is just one of the many shortcomings.

Ok, back to Zorro
Here we urgently need some reply on how to correctly implement the API functions.
What is also not so good is that Zorro queries ticks, instead of getting them pushed by default.
This means that the tick history of Zorro is very different to the brokers history with many missed ticks.
That makes comparison of tick based backtests impossible.

It is not impossible... in fact, I get every tick in my plugin:
https://github.com/AndrewAMD/SierraChartZorroPlugin

To get all ticks, you must implement SET_HWND. You must send a message to Zorro from another thread or process. Then Zorro will go ahead and collect that tick.

Hi Andrew,

thanks for reminding me about the HWND function.
Am I right that when calling PostMessage(hWindow, WM_APP + 1, 0, 0) a BrokerAsset call is triggered?
But how does Zorro know which asset was updated with a new tick?
Will Zorro request all prices for all subscribed assets?
And what about the "normal" periodically price requests with BrokerAsset, are they then stopped?
If not, then ticks might fetched more then once which seems a bit of an overkill.
This is all very unclear to me...

Calling the windows handle will make zorro call all subscribed assets.

Perhaps it is overkill, but if you're streaming your data, then you already have the data in-memory.

For the other questions, ask jcl.

EDIT: Clarity and correctness

Andrew, your plugin is written in native C/C++, which is a big advantage over plugins which relay on JVM languages.
Dukascopy is using Java and so we end up with a very high latency regarding tick fetching, because we must use a Java to C/C++ bridge.
I think that the most useful solution would be that Zorro provides update methods which get called by the plugin.
Currently it is the other way round

You do also have the option of writing a bridge in Java, and have your plugin communicate with it. The java bridge would be a server to zorro and a client to the broker.

This way, you can:
* Have the Java bridge send PostMessage, and
* Both the plugin and the bridge can be single-threaded (usually ideal)
* Have a native C++ plugin.

If you're not sure which protocol to use between the two, just use the DTC protocol and recycle my plugin.

Rationale is similar to what you see here:
https://www.sierrachart.com/index.php?page=doc/helpdetails76.html

(Mind you, these people have strong opinions, but I share some sentiment.)