fixed #895

[debris]

According to spec there are now two methods eth_getFitlerChanges and eth_getFilterLogs. But both of them are implemented in one method in parity.

docs

[tomusdrw]

My understanding of docs is that eth_getFilterLogs should not reset polling state.

So shouldn't scenario like that be possible?

1. eth_getFilterChanges (resets polling)
2. eth_getFilterLogs (returns changes happened since 1.)
3. eth_getFilterLogs (again returns changes happened since 1.)
4. eth_getFilterChanges (returns changes happened since 1. and resets polling)
5. eth_getFilterLogs (returns changes happened since 4.)

[arkpar]

As far as I understand eth_getFilterLogs returns all logs since genesis,
eth_getFilterChanges returns logs since last call to eth_getFilterChanges

[tomusdrw]

But it is parametrized with filter id which doesn't make much sense if it always returns all logs.

[arkpar]

All logs matching a filter

[tomusdrw]

True. It makes sense now.

[gavofyork]

@tomusdrw grumble gone?

[tomusdrw]

Mine is, but @arkpar has got on too. We can merge it as is, but cross check if this is really what was intended in docs.