Last modified: 2014-07-31 10:58:09 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T64513, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 62513 - Client-side upload API in core
Client-side upload API in core
Status: NEW
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
1.23.0
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 26751
  Show dependency treegraph
 
Reported: 2014-03-10 21:59 UTC by Matthew Flaschen
Modified: 2014-07-31 10:58 UTC (History)
17 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Matthew Flaschen 2014-03-10 21:59:00 UTC
I wasn't able to find a bug for this.

Core has the server part of the upload API (including handling stashing, etc.).  However, the clientside part is in UploadWizard.

This should be moved to core, at the correct abstraction level (promises, etc.), then UploadWizard should use that.
Comment 1 Brion Vibber 2014-03-13 00:08:56 UTC
MobileFrontend also has an uploading client implementation; are you thinking of some sort of low-level JS API wrapping file uploads that could be used by both, or specifically the high-level UploadWizard UI?
Comment 2 Matthew Flaschen 2014-03-21 20:19:49 UTC
(In reply to Brion Vibber from comment #1)
> MobileFrontend also has an uploading client implementation; are you thinking
> of some sort of low-level JS API wrapping file uploads that could be used by
> both, or specifically the high-level UploadWizard UI?

The actual low-level, client, upload part.  It should abstract away the transport, and support chunked uploads if the user has it enabled.  It shouldn't include UI, but it should make such UIs possible (callbacks for completion, failure, progress).

Basically some version of ApiUpload* (see also the Transport and Handler ones, like https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FUploadWizard.git/HEAD/resources%2Fmw.FormDataTransport.js from https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FUploadWizard.git/HEAD/resources .

It doesn't need to include all the UW stuff (e.g. Firefogg is probably not neeeded), just enough to get the job done with reasonable browser compatibility.

However, unlike UW, it should be in core and correctly abstracted (e.g. no transport.uploadObject.ui.setStatus in low-level code).  UploadWizard, MobileFrontend, PronunciationRecording, and probably other stuff I'm not thinking of should all be able to use it.
Comment 3 Bawolff (Brian Wolff) 2014-03-21 20:38:50 UTC
I would suggest special:upload could optionally use it. As it stands we have very limitted support for big file upload out of the box, and upwiz does not meet many of the third party use cases.
Comment 4 Matthew Flaschen 2014-07-30 23:35:30 UTC
See 597142b2e5a0c44b4efd369d1d339e3813aeefdf for a starting point; that doesn't appear to support chunked uploads.
Comment 5 Matthew Flaschen 2014-07-30 23:35:54 UTC
Just to be clear, that has been merged.
Comment 6 Fomafix 2014-07-31 10:58:09 UTC
Upload API would also be useful here:
Change-Id: I25a8a8832fab131e026fb062e7c4968193260b07

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links