Use get-size crate instead of size paramater of insert in foryer-memory

[xiaguan]

The two bugs found by fuzz all come from boundary cases in value size (0, out of bounds). I think using get-size crate instead of letting users set the value size could make things a bit easier, and the only extra overhead is a few addition operations during insert. If users want customization, they can just implement the GetSize trait themselves.
We could simplify insert to take just two parameters, aligning it more with common cache practices, making it more user-friendly.

[MrCroxx]

Hi @xiaguan .

By "the two bugs" I think you mean #338 and #339 . As I've replied in the issue. #338 is caused by a bug in S3FIFO implementation, and #339 is an expected behavior.

For foyer users, they might not want to weigh an entry by its memory size. e.g. One only wants to limit cached entries count. So a way to weigh each entry is necessary.

As far as my personal technical tastes are concerned, I prefer the way moka uses, a Weigher function. I've planned to refactor foyer for it. But there are still some important refactors before that.

[MrCroxx]

And thanks again for your recent ideas on improving the interface of foyer. It is nice to have you for foyer.

But just a reminder: A real user-friendly design must be built on meeting the user's needs first, not just makes the abstraction simple and clean.

[xiaguan]

1. If we could merge feat: use serde to serialize and deserialize storage key and value #365 ,which allows user to use foyer just with #[derive(Serde)].
2. And as you mentioned early, you want to unify the foyer-memory and foyer-storage.

Based on them, my main idea is, whether the user use or not use the ssd, the interface will reamin the same.
If we add get-size, it just another #[derive(GetSize)] for user.

And refer to bincode

The size of the encoded object will be the same or smaller than the size that the object takes up in memory in a running Rust program.

We could also use the get-size to estimate its storage size, too.

All in all, if we both support serde and get-size.
User could just use foyer as a LruCache with two automatic derive.

[MrCroxx]

Why not support get_set later as compression is already supported. 🤣 Sounds kind of majoring in the minors.

Let's make it clear. What bothers most with a Weigher?

[xiaguan]

It's not automatic. User need to pay some time to impl one.GetSize is much simple.
And it is not a bound of Value. The user may not uderstand how important the size is.

[MrCroxx]

User need to pay some time to impl one.
..
The user may not uderstand how important the size is.

On the contrary, IMO, a Weigher will force the user to better understand what weight means. An automatic method will make the user ignore the underlying details. What if the value contains a third-party struct that contains a raw pointer and doesn't support get_size? The implicit errors can confuse developers more, and it is also the design philosophy of Rust. get_size is a good tool, but it is not a standard.

[xiaguan]

If a cache item contains something like pointer. It's strange. How could it derive serde?

[MrCroxx]

It's something you cannot control with a thrid-party struct. If it can not be ser/de via serde, the user know a customized serializer/deserializer is needed. But get_size will return a wrong value without any compile error.