Why use filters - eth_getLogs vs eth_newFilter

Question

It seems to me eth_getLogs is much simpler than eth_newFilter + eth_getFilterLogs.

eth_getLogs has no need for installation, got same parameters, catches events retrospectively. What are use cases of filters at all?

As in my previous question:

from ethjsonrpc import EthJsonRpc
c = EthJsonRpc('127.0.0.1', 8545)
ADDRESS = "0xdb1154368ba2645e6c090f3d1f3ddd5c8c1f8008"
params = {
        "fromBlock": "0x01",
        "address": ADDRESS
    }
before = c.eth_newFilter(params)
for i in range(100):
    tx = c.call_with_transaction(c.eth_coinbase(), ADDRESS, 'setValue(uint32)', [i])
    receipt = c.eth_getTransactionReceipt(tx)
after = c.eth_newFilter(params)

print len(c.eth_getFilterLogs(before)) // 100
print len(c.eth_getFilterLogs(after)) // 0
print len(c.eth_getLogs(params)) // 100

Answer 1

eth_getLogs returns an array of filter logs. You pass in the parameters - e.g. fromBlock, toBlock, etc. - you want to discriminate against. These are the same parameter used by eth_newFilter.

eth_newFilter takes the same parameters, but returns a filterId instead of an array of logs. This ID can then be passed to eth_getFilterLogs, which returns the array of logs.

So far, so similar.

However, the filterID allows you to also use eth_getFilterChanges, which is a:

Polling method for a filter, which returns an array of logs which occurred since last poll.

Looking at the code, giving a filter an ID better allows for this polling feature because it provides a key against which we can store the last time the filter was checked.

If you don't care about polling, then you probably just want eth_getLogs.