search

square / tape

A lightning fast, transactional, file-based FIFO for Android and Java.
https://square.github.io/tape/
Apache License 2.0
2.47k stars 287 forks source link

Put Okio in ObjectQueue's API. #192

Closed NightlyNexus closed 6 years ago

NightlyNexus commented 6 years ago

wanted to see what it would look like. this isn't great so long as QueueFile only accepts byte arrays. worth changing QueueFile or just close this?

f2prateek commented 6 years ago

I don't have a strong preference one way or the other since there aren't multiple layers of bufferring for Okio to really shine here in terms of performance.

Also for our use case (segment) it would be nice to not have to add a dependency for Okio (and eventually the Kotlin stdlib with Okio 2).

NightlyNexus commented 6 years ago

this is really just for the API nicety of dealing with Okio types instead of java.io types and byte arrays. ah, i didn't realize the Segment SDK didn't have OkHttp and Okio in it.

f2prateek commented 6 years ago

Should we get this on v2? I'm still a soft -1 (because I want to avoid adding Okio to analytics-android) but I see the value for other clients and could be convinced otherwise.

NightlyNexus commented 6 years ago

I think having common converter implementation samples is good enough, so most ObjectQueue users don't have to look at OutputStream and byte array APIs too much.

f2prateek commented 6 years ago

Sounds good - I think a Moshi and Gson example should be sufficient?

NightlyNexus commented 6 years ago

or just Moshi. :P