Page MenuHomePhabricator

Create objectcache/BagOStuff library
Open, LowPublic

Description

Dependencies:

BagOStuff

MultiWriteBagOStuff

ReplicatedBagOStuff

WANObjectCache

  • EventRelayer

Event Timeline

Legoktm created this task.Sep 21 2016, 5:55 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 21 2016, 5:55 AM

I submitted https://gerrit.wikimedia.org/r/311921 to drop the Wikimedia\Assert dependency.

Legoktm updated the task description. (Show Details)Sep 21 2016, 7:45 AM
Legoktm added a subscriber: aaron.

@aaron, do you think we're ready to start doing this? How do we want to handle the ObjectFactory dependency?

bd808 added a subscriber: bd808.Oct 3 2016, 1:11 AM

How do we want to handle the ObjectFactory dependency?

The easiest way would probably be to move ObjectFactory to a tiny library.

Krinkle triaged this task as Low priority.
Krinkle moved this task from Untriaged to To Do on the Librarization board.Jan 26 2018, 7:47 PM
Krinkle updated the task description. (Show Details)Feb 10 2018, 6:57 AM

This would be great and would allow libraries such as https://github.com/addshore/psr-6-mediawiki-bagostuff-adapter to pull in the caching library for use during tests, rather than just missing the requirement entirely (as the only thing to require right now would be the whole of core)

We could move forward with this just excluding RESTBagOStuff for now

Removing the T110022 sub-task because creation a the library isn't blocked on having our HTTP abstraction published. Nothing in the relevant interfaces and utilities here uses HTTP functions. There's merely one BagOStuff implementation that MediaWiki has (RESTBagOStuff) that uses HTTP, which doesn't need to be in the library (and for many years, wasn't in core, either).

It's perfectly alright to leave that out of the initial publication library. Regardless of if and when we add it to the library, consumers of the library can and should be able at all times to make their own implementations and sub classes on top the library. This would effectively be an example of that within MediaWiki. (We did the same with includes/db/Oracle, which still remains to this date a MW-only implementation.)

Krinkle updated the task description. (Show Details)Dec 10 2018, 4:41 PM
aaron added a comment.Feb 16 2019, 7:02 AM

So is anything other than EventRelayer blocking this?

Nope. What do you want to call it? ObjectCache or BagOStuff?

Change 490963 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] objectcache: remove EventRelayer dependency from WANObjectCache

https://gerrit.wikimedia.org/r/490963

aaron added a comment.Feb 16 2019, 7:40 AM

Nope. What do you want to call it? ObjectCache or BagOStuff?

ObjectCache

tstarling added a subscriber: tstarling.

Would you move the classes to a namespace? If so, would the b/c aliases be part of the library?

Yes, the classes would be namespaced. The b/c aliases would go in core's includes/compat/.

Legoktm moved this task from To Do to In Dev on the Librarization board.Fri, Jun 21, 6:28 AM