Storage: Difference between revisions
(Added more info on static media) |
No edit summary |
||
Line 16: | Line 16: | ||
In addition, there's a "workbench" used during processing... it's just for temporary files during processing, and also for making local copies of stuff that might be on remote storage interfaces while transitionally moving/converting from the queue_store to the public store. See the workbench module documentation for more. |
In addition, there's a "workbench" used during processing... it's just for temporary files during processing, and also for making local copies of stuff that might be on remote storage interfaces while transitionally moving/converting from the queue_store to the public store. See the workbench module documentation for more. |
||
== Static |
== Static assets / staticdirect == |
||
On top of all that, there is some static media that comes bundled with your application. This stuff is kept in: |
On top of all that, there is some static media that comes bundled with your application. This stuff is kept in: |
Revision as of 00:37, 17 August 2011
Being a media publishing platform, storage is a big deal in MediaGoblin. As such there are a few systems that are storage-related that you may encounter while doing some MediaGoblin hacking.
MediaGoblin also comes with an extensible storage interface and several implementations mapping to it: basic local file storage, OpenStack "swift" style storage... and a few more plus the ability to write your own.
The storage systems attached to your app
Dynamic content: queue_store and public_store
Two instances of the StorageInterface come attached to your app. These are:
- queue_store: When a user submits a fresh piece of media for their gallery, before the Processing stage, that piece of media sits here in the queue_store. (It's possible that we'll rename this to "private_store" and start storing more non-publicly-stored stuff in the future...). This is a StorageInterface implementation instance. Visitors to your site probably cannot see it... it isn't designed to be seen, anyway.
- public_store: After your media goes through processing it gets moved to the public store. This is also a StorageInterface implelementation, and is for stuff that's intended to be seen by site visitors.
The workbench
In addition, there's a "workbench" used during processing... it's just for temporary files during processing, and also for making local copies of stuff that might be on remote storage interfaces while transitionally moving/converting from the queue_store to the public store. See the workbench module documentation for more.
Static assets / staticdirect
On top of all that, there is some static media that comes bundled with your application. This stuff is kept in:
mediagoblin/static/
These files are for mediagoblin base assets. Things like the CSS files, logos, etc. You can mount these at whatever location is appropriate to you (see the direct_remote_path option in the config file) so if your users are keeping their static assets at http://static.mgoblin.example.org/ but their actual site is at http://mgoblin.example.org/, you need to be able to get your static files in a where-it's-mounted agnostic way. There's a "staticdirector" attached to the request object. It's pretty easy to use; just look at this bit taken from the mediagoblin/templates/mediagoblin/base.html main template:
<link rel="stylesheet" type="text/css" href="Template:Request.staticdirect('/css/extlib/text.css')"/>
see? Not too hard. As expected, if you configured direct_remote_path to be http://static.mgoblin.example.org/ you'll get back http://static.mgoblin.example.org/css/extlib/text.css just as you'd probably expect.