Talk:Reading/Multimedia/Architecture/Tech Debt Backlog

= Fall 2013 Backlog = Discussion of issues for Fall 2013 backlog grooming.

Goal: find 4-6 big hitter problems that will give User:BDavis_(WMF) a roadmap to work on.

Chunked Upload
This seems to show up on everyone's list. It looks to me like there are several sub-issues here:
 * Use of php user session to store data is problematic due for several reasons
 * There are open bugs related to file size: 36587, 51730
 * job queue instability
 * deadlocks

I haven't found much documentation of how this component is intended to work. There is a small blurb on API:Upload and some other info at commons:Commons:Chunked_uploads.

I guess my question here is where to start? Should I do a deep dive with an initial goal of documenting the current implementation so it can be reviewed by a larger group for architectural flaws or should I just poke at the edges with small fixes and not worry about the big picture?

--BDavis (WMF) (talk) 18:13, 26 August 2013 (UTC)


 * documenting this is seeming like a pretty good place to start to me. --BDavis (WMF) (talk) 17:45, 28 August 2013 (UTC)

Domain Name
Constraining multimedia operations to the domain upload.wikimedia.org would be preferable, as it helps carriers participating in Wikipedia Zero distinguish low-bandwidth UI ( .zero.wikipedia.org) access from normal/high-bandwidth UI ( .m.wikipedia.org) access. upload.wikimedia.org access attempts originating from .zero.wikipedia.org page in general are supposed to cause a prompt to the user for whether to proceed, whereas similar Wikipedia Zero access attempts originating from .m.wikipedia.org don't as a general rule require such a prompt. Some users have higher capability devices yet access zero.wikipedia.org because of, the thinking goes, advertisement of that domain in areas that tend to have lower bandwidth.

--ABaso(WMF) (talk) 11:33, 28 August 2013 (UTC)
 * I can't imagine we have any plans to move images away from upload.wikimedia.org. Its good to have it in a separate domain for same-origin policy paranoia.


 * What about non-images multimedia such as video and audio? If there's a different domain name, it would be ideal if that domain name is on the same load balancer of upload.wikimedia.org, at least. Alternatively, up-front establishment of the load balancer IPs for such a forthcoming multimedia cluster would be helpful, as we hope to communicate a firm set of IP addresses for in-scope Wikipedia Zero-related servers. --ABaso(WMF) (talk) 20:16, 10 September 2013 (UTC)

SVG
Some notes on svg issues. I really don't think these are that high priority (relative to some of the other issues), although they would make commons folk happy if a bunch of the rsvg issues were fixed. Bawolff (talk) 17:57, 28 August 2013 (UTC)
 * svg lang not working: https://gerrit.wikimedia.org/r/#/c/69027/
 * svg rendering bugs:
 * rsvg upstream is not very active. I don't really think anyone is actively working on it. If we want to fix these, we may be looking at sending patches to upstream ourselves
 * Most of the bugs in Wikimedia/SVG Rendering component lack a minimal test case, are not filed upstream, and sometimes don't even have a concise description. Cleaning these up, so that they are all filed upstream, have a minimal test case/steps to reproduce, are tested to make sure they are still present on latest rsvg, would probably be a good thing. (That's more clerical work than dev work. Maybe we could sucker some folks into doing that in some sort of public bug day. You don't need knowledge of programming to do that, however you do need knowledge of svg standard, which means many commons contributors are qualified).