Storage: Difference between revisions

From GNU MediaGoblin Wiki
Jump to navigation Jump to search
(from)
 
(Added more info on static media)
Line 4: Line 4:


= The storage systems attached to your app =
= 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:
Two instances of the StorageInterface come attached to your app. These are:
Line 9: Line 11:
* '''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.
* '''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.
* '''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.
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 media ==
On top of all that, there is some static media that comes bundled with your application. (FIXME: Write this :))


On top of all that, there is some static media that comes bundled with your application. This stuff is kept in:
= StorageInterface and implementations =


mediagoblin/static/
Write me!

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="{{ 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.

= StorageInterface and implementations =

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 media

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.

StorageInterface and implementations