ABCDEFGHIJKLMNOPQRSTU
1
TimestampYour nameWhich model (as described above) should FIG pursue?What is your reason for favoring that approach?Are you a voting member of FIG?What project do you represent?Should we address multi-operations (multi-get, multi-set, multi-delete) in the base PSR-6 definition?How should we handle set() vs. save() actions?What is your reason for favoring that approach?
2
9/1/2013 18:56:42Larry GarfieldIt's trivial to emulate in user-space, so let's get 'er done now and have a more robust and reliable baseline.YesDrupalYes, as a required featureWe should have a separate save() method from set(), so that all setters may be called in any orderSRP applies to methods, too.
3
9/2/2013 2:56:23Gábor FásiNoSymfonyYes, as a required featureWe should have a separate save() method from set(), so that all setters may be called in any order
4
9/2/2013 4:18:23Jordi BoggianoIf you care about performance this makes sense, and that's the point of caches really.YesComposerYes, as a required featuresave() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);It's the most barebones and allows us to add helpers later if needed without shooting ourselves in the foot.
5
9/2/2013 10:03:30Guilherme BlancoDifferent drivers have completely diverging internal implementations.
Some of them "lock" the entire collection of items being unable to load when you're either traversing the list of items (getItems when retrieving all items). Other drivers like Memcache just don't provide the API to retrieve all items.
That's why I think it'll be better as a separate interface, which would allow more specific control over getItems. I'd separate as BulkOperationCache which would support all Multi-XXX we desire		YesDoctrineYes, as optional extra interfacessave() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);An items shouldn't know how to save itself. It violates SRP.
As an addendum to that, save (which I think should be renamed to set) should also support a second parameter which is the configuration to set a new index. That is where we open the possibility for drivers such as Riak to support timeout, number of replicas writes before return operation was ok (aka. write quorum), If-Modified-Since, etc.
My general recommendation is taking a look at my alternate cache proposal which explains why we should have a separate API (such as why TTL should be at Cache Collection level). Link: https://groups.google.com/forum/#!msg/php-fig/ciByHJoufSI/_XIIn7bpz5kJ
6
9/3/2013 9:25:46Michael CullumIf it's optional or available in some libs but not others then another lib doesn't have them in it's interface then you have problems taking one out and dropping in another.NophpBBYes, as a required featureWe should have a separate save() method from set(), so that all setters may be called in any order
7
9/3/2013 15:31:57Josh Hall-Bachnermulti-* operations provide a valuable way to abstract certain operations that are likely to be frequently used and enforcing them as mandatory ensures that they will be available in all compliant libraries.Nostash-bundleYes, as a required featuresave() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);This is probably the most elegant of the available options. Save on the item strikes me as an incorrect encapsulation. I was originally in favor of the first option, but when I wrote out an example I realized it's not clear enough.
8
9/5/2013 22:05:05Ryan McCueNoSimplePieIt's fine as-is with just multiple-get supportsave() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);The pool should be responsible for retrieving and storing all data, while the item itself should be for the actual item. If overriding the item, it doesn't make sense to override how it's saved, but it might make sense to override how it's stored (serialization/cleanup, e.g.).
9
9/6/2013 3:34:46Frédéric G. MARANDCaching is all about performance, and round-tripping to a cache server means more latency than needed if there is any way the backend can support it, so PSR-Cache should foster adoption of multiple operations by compliant backends.NoDrupalYes, as a required featureWe should have a separate save() method from set(), so that all setters may be called in any orderIf these other methods return the item, it allows for a compact style familiar in other environments, like $item->setTtl(60)->setTag('foo')->save();
10
9/6/2013 5:46:47Lukas Kahwe SmithMostly because I do not want to delay things much further.YesJackalopeIt's fine as-is with just multiple-get supportsave() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);I prefer the CacheItem to be as stupid as possible.
11
9/6/2013 10:18:03Phil SturgeonMulti-set gets bloody complicated, and letting the user get on with that in a loop seems just fine to me.YesPyroCMSIt's fine as-is with just multiple-get supportsave() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);You getItem from the pool, mess around with it using setters and getters, then commit it back to the pool with a save method. Consistent, extensible and logical.
12
9/6/2013 10:38:06Chuck BurgessIn combination with having Pool::save()/commit() be responsible for writing to the backend all the Item level set() changes that are pending, I think the Pool::commit() itself solves the multiSet() use case, while allowing for multiGet() to remain available.NophpDocumentorIt's fine as-is with just multiple-get supportsave() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);If Item::set() is going to be local only (object updated, not backend), then I think the Pool becomes responsible for committing changes, thus Pool::save() or even Pool::commit(). I'd lean towards commit() since the overall concept equates well to the database concept.

Pool::commit()/save() might perhaps also solve the multiSet() question. Having many Items that have set() new values on themselves, then having the Pool do a commit(), is effectively a multiSet() in my mind.
13
9/6/2013 11:06:18Amy StephenLoops on the get, set, delete are fine, no reason to complicateNoNo, remove it entirely for nowWe should have a separate save() method from set(), so that all setters may be called in any orderWould prefer a simplistic set approach and wait for tags, namespaces, etc. - but if that cannot be done, separate the set and save properly
14
9/6/2013 14:09:24Robert HafnerComplexity is the main reason for avoiding this for now. As it's been over 20 months that we've worked on this, I feel getting a simple version that people can use is vital.NoStashNo, remove it entirely for nowThere's no problem here. The inconsistency and SRP violation is OK.I disagree completely with the question, and think the last answer ("The inconsistency and SRP violation is OK") is misleading and will bias people away.

You are never going to set a value and not save it. Having different ways to set things makes no sense to me.
15
9/6/2013 22:53:24Paavo-Einari KaipilaSome kind of CacheItemCollection shipped with PSR-6 would be a good idea. The whole point of PHP-FIG is to reduce code in the world :) However, I find it hard to imagine any kind of multi-set/delete while still keeping api consistent.NoIt's fine as-is with just multiple-get supportThere's no problem here. The inconsistency and SRP violation is OK.Current set() is consistent with many existing caching systems (apc, wincache, redis, memcache etc.).
16
9/7/2013 17:23:24Gaelan SteeleI don't see a use case for this.NoDrupalYes, as optional extra interfacessave() should be a method on the pool, so you'd set the value on the item and then $pool->save($item);The pool handles saving. I think that is the most correct implementation in terms of Separation of Concerns.
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100