I've made a minor API change ApiUpload, for stashed files. It's not a commonly used API and the change shouldn't break anything external, but I figured I should post just in case.
Temporarily stashed files now have their metadata stored in the database instead of the session. This allows for some future feature expansion with regard to the image review and categorization process, and works around a memcached race condition that was preventing simultaneous uploads from working (see bug 26179https://bugzilla.wikimedia.org/show_bug.cgi?id=26179 )
The actual change to the API is pretty simple. First, the 'sessionkey' parameter has been superseded by 'filekey', though 'sessionkey' remains for compatibility. You can see that here: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/api/ApiUploa...
Second, the 'invalid-session-key' error has been replaced with 'invalid-file-key'.
Here is the entire change in code review: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92009
-Ian
On Tue, Jul 12, 2011 at 2:25 PM, Ian Baker ibaker@wikimedia.org wrote:
I've made a minor API change ApiUpload, for stashed files. It's not a commonly used API and the change shouldn't break anything external, but I figured I should post just in case.
Temporarily stashed files now have their metadata stored in the database instead of the session. This allows for some future feature expansion with regard to the image review and categorization process, and works around a memcached race condition that was preventing simultaneous uploads from working (see bug 26179< https://bugzilla.wikimedia.org/show_bug.cgi?id=26179%3E )
The actual change to the API is pretty simple. First, the 'sessionkey' parameter has been superseded by 'filekey', though 'sessionkey' remains for compatibility.
Seems to me like this doesn't need any client-visible changes; any objection to just leaving it labeled as is? It's a key to an 'upload session', so I wouldn't assume it has any specific relationship to HTTP session cookies...
-- brion
The actual change to the API is pretty simple. First, the 'sessionkey' parameter has been superseded by 'filekey', though 'sessionkey' remains
for
compatibility.
Seems to me like this doesn't need any client-visible changes; any objection to just leaving it labeled as is? It's a key to an 'upload session', so I wouldn't assume it has any specific relationship to HTTP session cookies...
Neilk and I talked about that, but it seemed misleading. While it could be argued that the UploadWizard implements the concept of an upload session, it doesn't really carry through to the API. Each key is linked to a specific file, whereas I'd expect an upload session to be an abstraction that could contain multiple files. Previously, sessionkey was really referring to the file key that was stored in the session.
We decided that changing it made sense since it was possible to deprecate the old name without removing it, which gave us both clarity and functionality. Had that been impossible, leaving it unchanged was the next-best option.
-Ian
On Tue, Jul 12, 2011 at 11:25 PM, Ian Baker ibaker@wikimedia.org wrote:
Temporarily stashed files now have their metadata stored in the database instead of the session. This allows for some future feature expansion with regard to the image review and categorization process, and works around a memcached race condition that was preventing simultaneous uploads from working (see bug 26179https://bugzilla.wikimedia.org/show_bug.cgi?id=26179 )
Great work people! I've really been waiting for this, and I'm glad that it has been finally implemented.
A remark about extensibility: in the future we might want to use the upload stash for more advanced features like asynchronous uploads and chunked uploads. I think the database schema should already be prepared for this, even if we're not using it. For this purpose I would at least add us_status. Perhaps Michael has some ideas what such a database schema should further incorporate.
Cheers, Bryan
In terms of a db schema friendly to chunks, we would probably want another table and associated it with a stashed file.
Russ was discussing adding support for appending files within the swft object store application logic, so we may not have to be concerned with storing chunk references in the db?
Another potential usage for a media stash is transcoding non-free formats. Here we could use the media stash as temporary location to put the media files while we transcode them. Once transcoded we could then move them into the published space. But I would not be too worried about incorporating that into the the DB schema until we get to implementation.
--michael
On 07/13/2011 12:30 AM, Bryan Tong Minh wrote:
Great work people! I've really been waiting for this, and I'm glad that it has been finally implemented.
A remark about extensibility: in the future we might want to use the upload stash for more advanced features like asynchronous uploads and chunked uploads. I think the database schema should already be prepared for this, even if we're not using it. For this purpose I would at least add us_status. Perhaps Michael has some ideas what such a database schema should further incorporate.
Cheers, Bryan
wikitech-l@lists.wikimedia.org