SmartCircuits new API

[jkt628]

fixes #35

[richo]

Thankyou! I will try to have a look and test it today. I am pretty sus of 6cba9da, and might rebase around it.

I totally see what you're driving at with it, but the fact that the cache never purges, as well as the fact that it makes reasoning about what the integration actually sees makes me pretty skeptical. As a concrete example, it seems that sometimes they just return an empty body and if that winds up in the cache I think the whole integration will wedge itself.

[richo]

Oh thankyou! I was happy to go around it, but appreciate you rebasing :)

[jkt628]

Thankyou! I will try to have a look and test it today. I am pretty sus of 6cba9da, and might rebase around it.

I totally see what you're driving at with it, but the fact that the cache never purges, as well as the fact that it makes reasoning about what the integration actually sees makes me pretty skeptical. As a concrete example, it seems that sometimes they just return an empty body and if that winds up in the cache I think the whole integration will wedge itself.

this is intended only for periodic calls and the cache purges every time its API is invoked, for any client including dead and gone. i can tell you from experience it makes a big difference in HTTP traffic, especially with async.

[jkt628]

I am pretty sus

what is "sus"???

[jkt628]

fixed statistics

[jkt628]

bump

[richo]

Can you elaborate on what the usecase for this is?

[jkt628]

to avoid off-by-one bugs circuits[0] is always None. the constructor accepts 3 or 4 length list, usually from a generator (length=3), but could be a copy operation (length=4). this code enforces the restriction.

[richo]

I see. To me this just really increases the chances of off by one bugs? As a casual reader I would never really expect there to be a phantom 0th element that I need to understand or care about. I think if you are really worried about this class of problem you probably want to just make the list private and make some accessors that always do the right thing? It's not like there can be arbitrarily many of them

[jkt628]

changed to explicit dict. note 2 is not present if circuits 1 & 2 are merged.