[Manifest] About Expiration

[imclint21]

Hi,

About object expirations, what do you think @CephalonRho? We have two ways to proceed:

1. Make a loop in a separated thread and drop items when the time is due.
2. Check the expiration date when a GET is called and drop the object if it's expired.

Best regards

[shuni64]

I think the second option should be the first step of implementing this. Regardless of any other optimizations such as dropping them in the background, a client should never be able to access an entry after it has expired, so there should be a check every time the entry is accessed.

Shouldn't be a big problem to implement the actual expiration part of this, I'm more concerned about how we want to set the expiration time. A way to set individual lifetimes on entry creation would be good, but we probably also want to have default lifetimes for everything and a way to change entry lifetimes after creation (probably with PATCH when that happens).

[imclint21]

Happy new year! 🍾

Something like this is a possiblity, but it's also possible with an http header like X-Expiration.

curl -X PATCH -d 'ttl=3600' https://localhost:7021/api/kv/hello_world/

I also think that a way to specify expiration at the creation is a good and needed things!

Anyway we need to achieve the PATCH part and also determine if we use JSON or other.

[shuni64]

Didn't think about http headers, definitely a good option here. Discussion about the PATCH method belongs in #44, but it's not a requirement for entry expiration anyway as long as there is another way to set them. I would use headers to set the TTL when creating entries and keep PATCH completely separate with it's own format, whatever that will be.

[imclint21]

TTL and expiration is not really the same things, I mean we also need to define if we use TTL or an absolute expiration datetime (by example with a timestamp) or maybe the both?

The expiration will be also a problem for the persistence, but we will see that in the proper issue (#17)