[RFC] Simpfilied cache

[marcj]

Initial RFC idea: php-cds/php-cds#7

All discussions about a "advanced" version please here: [RFC] Advanced cache

[CarwynNelson]

Back on the discussion of a simple Caching interface, what does everybody think should be covered in such an interface?

I'm thinking it could be as simple as functions for get, set and delete?

[marcj]

It think we should work on a simple cache interface that covers > 95% use cases.

We could work on additional more advanced interface as new recommendation on top of that simple cache interface later.

CDR-simple-cache = we discuss now
CDR-advanced-cache = we discuss later (which will be much more work I guess)

Although I'm really not sure about advanced as its too abstract (could contain trees, invalidations, bulks or just has method), but we should discuss that when simple-cache is done :)

[CarwynNelson]

@marcj Agreed. Does anybody have any objections to there being just get, set and delete methods? Are there any flaws to this that might not be immediately apparent?

[Isinlor]

@CarwynNelson All the flaws were already stated. Race conditions and how to recognize a miss. I don't think that there is consensus on this methods.

[CarwynNelson]

@Isinlor I thought it was agreed / discussed in depth that dealing with race conditions would be down to the implementation, and not the interface to solve?

As to how to recognise a miss, I don't think I fully understand that discussion, so I think I'll leave that to people who know what they are talking about :)

[Isinlor]

@CarwynNelson Interface that you propose is preventing you from dealing with race conditions. This interface makes it impossible, so it is not implementation detail.

[marcj]

@CarwynNelson: All the flaws were already stated. Race conditions and how to recognize a miss.

Race conditions should be up to the implementation. If the implementation wants to provide transaction secureness they can add additional methods/subclass the simple cache interface.

Recognizing a miss is possible with get('foo') === null.

[samdark]

I think php-cds/php-cds#7 (comment) is a good solution. Even less methods so it's perfectly simple and with handy syntax. Also implementing libraries are able to deal with all the issues w/o changing interface.

[CarwynNelson]

@Isinlor You seem to know much more about caching than I do, so I'll trust that you are correct. Could you explain what about simple get, set and delete in the interface does not allow the implementation to deal with race conditions?

[Isinlor]

@CarwynNelson After a delete consumer of the interface have no way of knowing if the value is not already being computed by other process. This requires locking. You could delay get in all places that are asking for the data and let one process handle computation inside get, but then get method needs to know how to make the computations and this leads to php-cds/php-cds#7 (comment)

[marcj]

@Isinlor: How do we reach consensus on which solution to progress?

If someone feels the need to create another discussion issue regarding a different "simple cache" idea or a advanced cache anyone is free to create those. People will reply and you'll see if it was a good idea :P
I'd rather want to introduce as less bureaucracy as possible, so it becomes a self-adjusting process.

However my 2 cents: I think we are still in the middle of a discussion, so I think making votes for a particular interface doesn't make sense yet.

[Isinlor]

@marcj At some point this process will need to reach conclusion or we will end up with two or more interfaces trying to achieve the same. Taking all propositions and allowing to vote on them in one place without noise of discussion seems like the best idea in my opinion and will lead fastest to the one interface being obviously preferred. But I don't mind to wait to see if it can be done just by discussion. It's an interesting social experiment :) .

[marcj]

You are probably right. :) Maybe like here: php-cds/php-cds#4 But honestly, I'm not sure how to organise it "the perfect way". I believe in the community, that someone has an outstanding idea :P

[CarwynNelson]

@marcj @Isinlor Are we able to reach any conclusions at this point in the discussion? Many people seem to like the idea proposed by @Isinlor, so possibly we could focus discussion on something similar to that?

Apologies if I seem to have missed something from before, just trying to focus the discussion on maybe getting closer to an interface proposal.