Yes. The successive mRefs arrays can be saved as extension data during parse. Then, the array can be json_encoded and compressed during LinksUpdate, stored in page_props, in two parts if the size is excessive, and saved in a cache.

That's how I plan on handling T124840, and I think it would work for MobileFrontend as well.

I suppose that proposing serializing to JSON is to save a few bytes over just putting the data structure into ParserOutput's extension data and allowing it to be serialized along with the rest of the object?

Note that, if the data is only needed when you have a ParserOutput, extension data would seem likely to serve the purpose without the extra size limitations that using page_props introduces.

I suppose that proposing serializing to JSON is to save a few bytes over just putting the data structure into ParserOutput's extension data and allowing it to be serialized along with the rest of the object?

I'm not sure why JSON was chosen here – perhaps it was a simple miscommunication. I think that serialising the data structure once to then serialise it again (it'd be serialized when it's stored with ParserOutput#setExtensionData, right?) would be wasteful.

In T125134#1979488, @Cenarium wrote:

Yes. The successive mRefs arrays can be saved as extension data during parse. Then, the array can be json_encoded and compressed during LinksUpdate, stored in page_props, in two parts if the size is excessive, and saved in a cache.

That's how I plan on handling T124840, and I think it would work for MobileFrontend as well.

That'd be ideal. When are you planning on starting this work? Is this something that we could collaborate on or, if not, something that I can help out on in any way? I'd be more than happy to do the MobileFrontend -side of this.

In T125134#1981196, @phuedx wrote:

I suppose that proposing serializing to JSON is to save a few bytes over just putting the data structure into ParserOutput's extension data and allowing it to be serialized along with the rest of the object?

I'm not sure why JSON was chosen here – perhaps it was a simple miscommunication. I think that serialising the data structure once to then serialise it again (it'd be serialized when it's stored with ParserOutput#setExtensionData, right?) would be wasteful.

Well, serialize( json_encode( $foo ) ) does tend to be a bit smaller than serialize( $foo ), because PHP's format is more verbose except when it comes to long strings containing lots of double-quotes and backslashes. That might have been a concern that outweighs the added complexity of having to encode and decode the JSON blob.

In T125134#1981197, @phuedx wrote:

That'd be ideal. When are you planning on starting this work? Is this something that we could collaborate on or, if not, something that I can help out on in any way? I'd be more than happy to do the MobileFrontend -side of this.

I'll probably do this this weekend. I think I can do the Cite extension side of this, of course I'd like your feedback on it.
I'll do a function to return the refs that first tries the cache then the db if there's a cache miss. Is it okay if it returns the data in array form ?
For the cache, there's no need to json_encode it, and as you mentioned above if it's no needed we should avoid it. (The bd needs it but it would be handled internally by Cite.)

Thanks for everyone's answers!
@Cenarium I'll assign you to T123290 and we'll help as best we can next week!