--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"
+lang="en" xml:lang="en">
+<head>
+<title>GNU MediaGoblin</title>
+<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"/>
+<meta name="generator" content="Org-mode"/>
+<meta name="generated" content="2011-03-27 23:35:24 CDT"/>
+<meta name="author" content="Christopher Allan Webber"/>
+<meta name="description" content=""/>
+<meta name="keywords" content=""/>
+<style type="text/css">
+ <!--/*--><![CDATA[/*><!--*/
+ html { font-family: Times, serif; font-size: 12pt; }
+ .title { text-align: center; }
+ .todo { color: red; }
+ .done { color: green; }
+ .tag { background-color: #add8e6; font-weight:normal }
+ .target { }
+ .timestamp { color: #bebebe; }
+ .timestamp-kwd { color: #5f9ea0; }
+ .right {margin-left:auto; margin-right:0px; text-align:right;}
+ .left {margin-left:0px; margin-right:auto; text-align:left;}
+ .center {margin-left:auto; margin-right:auto; text-align:center;}
+ p.verse { margin-left: 3% }
+ pre {
+ border: 1pt solid #AEBDCC;
+ background-color: #F3F5F7;
+ padding: 5pt;
+ font-family: courier, monospace;
+ font-size: 90%;
+ overflow:auto;
+ }
+ table { border-collapse: collapse; }
+ td, th { vertical-align: top; }
+ th.right { text-align:center; }
+ th.left { text-align:center; }
+ th.center { text-align:center; }
+ td.right { text-align:right; }
+ td.left { text-align:left; }
+ td.center { text-align:center; }
+ dt { font-weight: bold; }
+ div.figure { padding: 0.5em; }
+ div.figure p { text-align: center; }
+ textarea { overflow-x: auto; }
+ .linenr { font-size:smaller }
+ .code-highlighted {background-color:#ffff00;}
+ .org-info-js_info-navigation { border-style:none; }
+ #org-info-js_console-label { font-size:10px; font-weight:bold;
+ white-space:nowrap; }
+ .org-info-js_search-highlight {background-color:#ffff00; color:#000000;
+ font-weight:bold; }
+ /*]]>*/-->
+</style>
+<script type="text/javascript">
+<!--/*--><![CDATA[/*><!--*/
+ function CodeHighlightOn(elem, id)
+ {
+ var target = document.getElementById(id);
+ if(null != target) {
+ elem.cacheClassElem = elem.className;
+ elem.cacheClassTarget = target.className;
+ target.className = "code-highlighted";
+ elem.className = "code-highlighted";
+ }
+ }
+ function CodeHighlightOff(elem, id)
+ {
+ var target = document.getElementById(id);
+ if(elem.cacheClassElem)
+ elem.className = elem.cacheClassElem;
+ if(elem.cacheClassTarget)
+ target.className = elem.cacheClassTarget;
+ }
+/*]]>*///-->
+</script>
+
+</head>
+<body>
+<div id="content">
+
+<h1 class="title">GNU MediaGoblin</h1>
+
+
+<div id="table-of-contents">
+<h2>Table of Contents</h2>
+<div id="text-table-of-contents">
+<ul>
+<li><a href="#sec-1">1 About </a></li>
+<li><a href="#sec-2">2 Milestones </a>
+<ul>
+<li><a href="#sec-2_1">2.1 Basic image hosting </a></li>
+<li><a href="#sec-2_2">2.2 Multi-media hosting (including video and audio) </a></li>
+<li><a href="#sec-2_3">2.3 API(s) </a></li>
+<li><a href="#sec-2_4">2.4 Federation </a></li>
+<li><a href="#sec-2_5">2.5 Plugin system </a></li>
+</ul>
+</li>
+<li><a href="#sec-3">3 Technology </a>
+<ul>
+<li><a href="#sec-3_1">3.1 Why python </a></li>
+<li><a href="#sec-3_2">3.2 Why mongodb </a></li>
+<li><a href="#sec-3_3">3.3 Why wsgi minimalism / Why not Django </a></li>
+</ul>
+</li>
+</ul>
+</div>
+</div>
+
+<div id="outline-container-1" class="outline-2">
+<h2 id="sec-1"><span class="section-number-2">1</span> About </h2>
+<div class="outline-text-2" id="text-1">
+
+
+<p>
+What is MediaGoblin? I'm shooting for:
+</p>
+<ul>
+<li>Initially, a place to store all your photos that's as awesome as,
+ more awesome than, existing proprietary solutions
+</li>
+<li>Later, a place for all sorts of media, such as video, music, etc
+ hosting.
+</li>
+<li>Federated, like statusnet/ostatus (we should use ostatus, in fact!)
+</li>
+<li>Customizable
+</li>
+<li>A place for people to collaborate and show off original and derived
+ creations
+</li>
+<li>Free, as in freedom. Under the GNU AGPL, v3 or later. Encourages
+ free formats and free licensing for content, too.
+</li>
+</ul>
+
+<p>
+Wow! That's pretty ambitious. Hopefully we're cool enough to do it.
+I think we can.
+</p>
+<p>
+It's also necessary, for multiple reasons. Centralization and
+proprietization of media on the internet is a serious problem and
+makes the web go from a system of extreme resilience to a system
+of frightening fragility. People should be able to own their data.
+Etc. If you're reading this, chances are you already agree though. :)
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2" class="outline-2">
+<h2 id="sec-2"><span class="section-number-2">2</span> Milestones </h2>
+<div class="outline-text-2" id="text-2">
+
+
+<p>
+Excepting the first, not necessarily in this order.
+</p>
+
+</div>
+
+<div id="outline-container-2_1" class="outline-3">
+<h3 id="sec-2_1"><span class="section-number-3">2.1</span> Basic image hosting </h3>
+<div class="outline-text-3" id="text-2_1">
+
+</div>
+
+</div>
+
+<div id="outline-container-2_2" class="outline-3">
+<h3 id="sec-2_2"><span class="section-number-3">2.2</span> Multi-media hosting (including video and audio) </h3>
+<div class="outline-text-3" id="text-2_2">
+
+</div>
+
+</div>
+
+<div id="outline-container-2_3" class="outline-3">
+<h3 id="sec-2_3"><span class="section-number-3">2.3</span> API(s) </h3>
+<div class="outline-text-3" id="text-2_3">
+
+</div>
+
+</div>
+
+<div id="outline-container-2_4" class="outline-3">
+<h3 id="sec-2_4"><span class="section-number-3">2.4</span> Federation </h3>
+<div class="outline-text-3" id="text-2_4">
+
+
+<p>
+Maybe this is 0.2 :)
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2_5" class="outline-3">
+<h3 id="sec-2_5"><span class="section-number-3">2.5</span> Plugin system </h3>
+<div class="outline-text-3" id="text-2_5">
+
+
+</div>
+</div>
+
+</div>
+
+<div id="outline-container-3" class="outline-2">
+<h2 id="sec-3"><span class="section-number-2">3</span> Technology </h2>
+<div class="outline-text-2" id="text-3">
+
+
+<p>
+I have a pretty specific set of tools that I expect to use in this
+project. Those are:
+</p>
+<ul>
+<li><b><a href="http://python.org/">Python</a>:</b> because I love, and know well, the language
+</li>
+<li><b><a href="http://www.mongodb.org/">MongoDB</a>:</b> a "document database". Because it's extremely flexible
+ (and scales up well, but I guess not down well)
+</li>
+<li><b><a href="http://namlook.github.com/mongokit/">MongoKit</a>:</b> a lightweight ORM for mongodb. Helps us define our
+ structures better, does schema validation, schema evolution, and
+ helps make things more fun and pythonic.
+</li>
+<li><b><a href="http://jinja.pocoo.org/docs/">Jinja2</a>:</b> for templating. Pretty much django templates++ (wow, I
+ can actually pass arguments into method calls instead of tediously
+ writing custom tags!)
+</li>
+<li><b><a href="http://wtforms.simplecodes.com/">WTForms</a>:</b> for form handling, validation, abstraction. Almost just
+ like Django's templates,
+</li>
+<li><b><a href="http://pythonpaste.org/webob/">WebOb</a>:</b> gives nice request/response objects (also somewhat djangoish)
+</li>
+<li><b><a href="http://pythonpaste.org/deploy/">Paste Deploy</a> and <a href="http://pythonpaste.org/script/">Paste Script</a>:</b> as the default way of configuring
+ and launching the application. Since MediaGoblin will be fairly
+ wsgi minimalist though, you can probably use other ways to launch
+ it, though this will be the default.
+</li>
+<li><b><a href="http://routes.groovie.org/">Routes</a>:</b> for URL routing. It works well enough.
+</li>
+<li><b><a href="http://jquery.com/">JQuery</a>:</b> for all sorts of things on the javascript end of things,
+ for all sorts of reasons.
+</li>
+<li><b><a href="http://beaker.groovie.org/">Beaker</a>:</b> for sessions, because that seems like it's generally
+ considered the way to go I guess.
+</li>
+<li><b><a href="http://somethingaboutorange.com/mrl/projects/nose/1.0.0/">nose</a>:</b> for unit tests, because it makes testing a bit nicer.
+</li>
+<li><b><a href="http://celeryproject.org/">Celery</a>:</b> for task queueing (think resizing images, encoding
+ video) because some people like it, and even the people I know who
+ don't don't seem to know of anything better :)
+</li>
+<li><b><a href="http://www.rabbitmq.com/">RabbitMQ</a>:</b> for sending tasks to celery, because I guess that's
+ what most people do. Might be optional, might also let people use
+ MongoDB for this if they want.
+</li>
+</ul>
+
+
+</div>
+
+<div id="outline-container-3_1" class="outline-3">
+<h3 id="sec-3_1"><span class="section-number-3">3.1</span> Why python </h3>
+<div class="outline-text-3" id="text-3_1">
+
+
+<p>
+Because I (Chris Webber) know Python, love Python, am capable of
+actually making this thing happen in Python (I've worked on a lot of
+large free software web applications before in Python, including
+<a href="http://mirocommunity.org/">Miro Community</a>, the <a href="http://miroguide.org">Miro Guide</a>, a large portion of
+<a href="http://creativecommons.org/">Creative Commons' site</a>, and a whole bunch of things while working at
+<a href="http://www.imagescape.com/">Imaginary Landscape</a>). I know Python, I can make this happen in
+Python, me starting a project like this makes sense if it's done in
+Python.
+</p>
+<p>
+You might say that PHP is way more deployable, that rails has way more
+cool developers riding around on fixie bikes, and all of those things
+are true, but I know Python, like Python, and think that Python is
+pretty great. I do think that deployment in Python is not as good as
+with PHP, but I think the days of shared hosting are (thankfully)
+coming to an end, and will probably be replaced by cheap virtual
+machines spun up on the fly for people who want that sort of stuff,
+and Python will be a huge part of that future, maybe even more than
+PHP will. The deployment tools are getting better. Maybe we can use
+something like Silver Lining. Maybe we can just distribute as .debs
+or .rpms. We'll figure it out.
+</p>
+<p>
+But if I'm starting this project, which I am, it's gonna be in Python.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-3_2" class="outline-3">
+<h3 id="sec-3_2"><span class="section-number-3">3.2</span> Why mongodb </h3>
+<div class="outline-text-3" id="text-3_2">
+
+
+<p>
+In case you were wondering, I am not a NOSQL fanboy, I do not go
+around telling people that MongoDB is web scale. Actually my choice
+for MongoDB isn't scalability, though scaling up really nicely is a
+pretty good feature and sets us up well in case large volume sites
+eventually do use MediaGoblin. But there's another side of
+scalability, and that's scaling down, which is important for
+federation, maybe even more important than scaling up in an ideal
+universe where everyone ran servers out of their own housing. As a
+memory-mapped database, MongoDB is pretty hungry, so actually I spent
+a lot of time debating whether the inability to scale down as nicely
+as something like SQL has with sqlite meant that it was out.
+</p>
+<p>
+But I decided in the end that I really want MongoDB, not for
+scalability, but for flexibility. Schema evolution pains in SQL are
+almost enough reason for me to want MongoDB, but not quite. The real
+reason is because I want the ability to eventually handle multiple
+media types through MediaGoblin, and also allow for plugins, without
+the rigidity of tables making that difficult. In other words,
+something like:
+</p>
+
+
+
+<pre class="example">{"title": "Me talking until you are bored",
+ "description": "blah blah blah",
+ "media_type": "audio",
+ "media_data": {
+ "length": "2:30",
+ "codec": "OGG Vorbis"},
+ "plugin_data": {
+ "licensing": {
+ "license": "http://creativecommons.org/licenses/by-sa/3.0/"}}}
+</pre>
+
+
+
+<p>
+Being able to just dump media-specific information in a media_data
+hashtable is pretty great, and even better is having a plugin system
+where you can just let plugins have their own entire key-value space
+cleanly inside the document that doesn't interfere with anyone else's
+stuff. If we were to let plugins to deposit their own information
+inside the database, either we'd let plugins create their own tables
+which makes SQL migrations even harder than they already are, or we'd
+probably end up creating a table with a column for key, a column for
+value, and a column for type in one huge table called "plugin_data" or
+something similar. (Yo dawg, I heard you liked plugins, so I put a
+database in your database so you can query while you query.) Gross.
+</p>
+<p>
+I also don't want things to be too lose so that we forget or lose the
+structure of things, and that's one reason why I want to use MongoKit,
+because we can cleanly define a much structure as we want and verify
+that documents match that structure generally without adding too much
+bloat or overhead (mongokit is a pretty lightweight wrapper and
+doesn't inject extra mongokit-specific stuff into the database, which
+is nice and nicer than many other ORMs in that way).
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-3_3" class="outline-3">
+<h3 id="sec-3_3"><span class="section-number-3">3.3</span> Why wsgi minimalism / Why not Django </h3>
+<div class="outline-text-3" id="text-3_3">
+
+
+<p>
+If you notice in the technology list above, I list a lot of components
+that are very <a href="http://www.djangoproject.com/">Django-like</a>, but not actually Django components. What
+can I say, I really like a lot of the ideas in Django! Which leads to
+the question: why not just use Django?
+</p>
+<p>
+While I really like Django's ideas and a lot of its components, I also
+feel that most of the best ideas in Django I want have been
+implemented as good or even better outside of Django. I could just
+use Django and replace the templating system with Jinja2, and the form
+system with wtforms, and the database with MongoDB and MongoKit, but
+at that point, how much of Django is really left?
+</p>
+<p>
+I also am sometimes saddened and irritated by how coupled all of
+Django's components are. Loosely coupled yes, but still coupled.
+WSGI has done a good job of providing a base layer for running
+applications on and <a href="http://pythonpaste.org/webob/do-it-yourself.html">if you know how to do it yourself</a> it's not hard or
+many lines of code at all to bind them together without any framework
+at all (not even say <a href="http://pylonshq.com/">Pylons</a>, <a href="http://docs.pylonsproject.org/projects/pyramid/dev/">Pyramid</a>, or <a href="http://flask.pocoo.org/">Flask</a> which I think are still
+great projects, especially for people who want this sort of thing but
+have no idea how to get started). And even at this already really
+early stage of writing MediaGoblin, that glue work is mostly done.
+</p>
+<p>
+Not to say I don't think Django isn't great for a lot of things. For
+a lot of stuff, it's still the best, but not for MediaGoblin, I think.
+</p>
+<p>
+One thing that Django does super well though is documentation. It
+still has some faults, but even with those considered I can hardly
+think of any other project in Python that has as nice of documentation
+as Django. It may be worth
+<a href="http://pycon.blip.tv/file/4881071/">learning some lessons on documentation from Django</a>, on that note.
+</p>
+<p>
+I'd really like to have a good, thorough hacking-howto and
+deployment-howto, especially in the former making some notes on how to
+make it easier for Django hackers to get started.
+</p></div>
+</div>
+</div>
+<div id="postamble">
+<p class="author">Author: Christopher Allan Webber</p>
+<p class="creator">Org version 7.5 with Emacs version 24</p>
+<a href="http://validator.w3.org/check?uri=referer">Validate XHTML 1.0</a>
+</div>
+</div>
+</body>
+</html>
projects / mediagoblin.git / commitdiff