Synchronous fetch

[mikeRozen]

It seems my issue is similar to https://github.com/Haneke/HanekeSwift/issues/168
But is there a way to fetch data in Synchronous way. (it doesn't have to be image/images but some small data like state.)(of course I can group or use semaphore but it's too much )

[tankista]

It is total nonsense that caching library does not support synchronous calls. I wish I had never used this library, authors are ignoring this for a long time now. It is very nice that they are enforcing asynchronous calls because <"put whatever bullshit you want">, but there are situations where you simply must use synchronous calls. Even GCD can't be used, because their completion blocks are called on main thread. It is addressed here 2 years ago, but again, ignored #396

[smhk]

Hi @tankista - can you help me understand in what situation you would want a blocking, synchronous call? I'm not sure I understand .. cheers!

[tankista]

I am using image browser library that allows me to use custom caching and because I am using HanekeSwift to cache images, I wanted to provide it. However, their protocol supports synchronous method:

func imageForKey(_ key: String) -> UIImage?

I have no other option but to load image synchronously. I tried to use GCD and dispatch groups, but Haneke is calling completion blocks on main thread which are already blocked by dispatch group so it always timeouts. Solution, where I could provide my own dispatch queue would be sufficient as I would be able to make the call synchronous manually. See
#396

[smhk]

Hmm, it does seem pretty unusual that that library has only synchronous loading!!

Thanks for the explanation. I don't really know what the solution would be there. Cheers

[tankista]

@smhk well not everything is perfect on this world, and solution is mentioned in my comment above.

[smhk]

hi @tankista,

I guess the problem is this. To be clear, I am saying this is POSSIBLY a problem:

1. it is very unusual for a library like that to have only locking calls

2. idea is to make big change to Haneke, to allow for that unusual library

3. then,

(a) everyone has to have that feature in Haneke, only so it works with unusual library

(b) ongoing work/maintenance applied to the feature, only for that library

I am just pointing out in general, the danger of such a thing.

Food for thought! Maybe it is not wise to change Haneke in such a way, IDK

cheers

[luxmentis]

Hi @smhk,

I'm evaluating Haneke and saw this thread.

Here's another use case for you - Apple's own NSFileProviderExtension.item(for identifier: NSFileProviderItemIdentifier). It requires you to resolve an id to a stored object, synchronously. The call won't involve a network fetch, is expected to block, and probably isn't running on the main thread.

This is me wanting to use Haneke as a disk-based key-value store with a memory layer for efficiency. (Aside: would need to be able to change the disk storage path for this to work.)

The project seems focused specifically on being a cache for network resources. But at the lower level you have a generic key-value store which is non-trivial to write and would be useful to people. In this context, having the option of blocking fetches make a lot more sense.