[IMC-Video] video.indymedia.org - a warning: beware of complex systems!

[mark burdett]

Hi, i'd love to find/use a CMS that renders much of a site to static 
HTML.  I just don't want to create and maintain this CMS over the long 
term for one site that uses it.  Ideally this CMS would have a large 
developer community and lots of add-on components available that we 
could just drop in to add extra functionality.

I feel that once you add in all the functionality that a video.indy site 
really needs -- multilingual interfaces, content translation, different 
skins (e.g. for handheld user agents), tagging, rating/voting, 
aggregation, etc. you're going to find it worthwhile to use already 
available platforms as a starting point.  it's doing to take a lot of 
hours to build this stuff, bug test it, do security audits etc.

one thing that I think is important, and the more popular CMS platforms 
help you do, is empowering site admins to add functionality to the site 
without relying on developers (for example drupal modules like CCK and 
Views).

I'm willing to help find hardware to host the site even if it's running 
something heavyweight like Plone or drupal.  I don't have experience 
scaling plone (some folks in our local colocation coop do), but I know 
with drupal there's a lot you can do to move it closer to the realm of 
static HTML.  setup opcode caching, enable drupal caching, ideally use 
memcache or filecache instead of the built-in db cache.  put some squid 
servers in front to handle the load.
 
I hate to see us spend a lot of time building and maintaining custom 
indymedia software when what we're doing has become increasingly common.

Note I say this even though I help maintain custom software for my local 
indymedia site which does render the site to static php and html.  But 
I'm kinda tired of doing that (and what we have is php spaghetti 
compared to drupal :p)

--mark

On Tue, 20 Nov 2007 10:16:34 -0800, Sasha Costanza-Chock wrote:
> Dear TJ,
> 
> In quick response to your comments:
> 
> I think there may be a bit of a misunderstanding, let me try to be more
> clear. From discussions here over the last year there seem to be several
> different indymedia video distribution projects that people want to work
> on.
> 
> 1. Maximum speed, minimal resources. Current solution is
> ivdn.indymedia.org (currently also video.indymedia.org): the existing
> system, designed for ftp upload of large files, focused on distribution
> of more 'highly produced' video content, meant to be a place where local
> imcs can download screening quality copies of indymedia films for local
> screening. The advantage: simple and already working (although down...)
> Disadvantage: built and maintained by very few people (one, two?), which
> is why it is currently down: if that person becomes too busy with other
> projects, nothing happens to get the site back up, let alone development
> and improved functionality. It sounds to me like you are most interested
> in getting this back up immediately, which is great, thank you for your
> energy! Your idea of POH fits here, also.
> 
> 2. Become competitive with ease of use and functionality of corporate
> video sites. This can be done either through modules for existing IMCs
> (see indybay.org video implementation) or through a new indymedia video
> platform, probably (but not definitely) based on plumi or filmforge,
> designed to replicate (at least) the functionalities of all the popular
> video sharing sites, because there is a reason those functionalities are
> popular! ie the average net user (read: web forms, not FTP) needs to be
> able to upload video, have it automatically transcoded, easily embed it
> elsewhere, tag, rate and comment, etc. This is a longer term process
> which is also related to the broader IMC discussion about CMS. That's
> happening on another list, on docs.indy, and I think there's an IRC
> meeting about it tomorrow, but sorry i don't have all the links handy.
> try asking in IRC on #tech or #cms.
> 
> Why do we need 2? I'll give an example. I work with grassroots immigrant
> rights organizations in Los Angeles. Some of them are shooting video of
> their actions, and then they upload them to YouTube or MySpace video. I
> have discussed the problem with them of supporting these corporate
> spaces where your work is appropriated, you do free labor to generate ad
> revenue, your IP address is tracked and your work can be taken down
> based on corporate or government requests. However, I don't currently
> have a good alternative to show them because LA indymedia interface is
> clunky as shit, archive.org interface is even worse, video.indy is down
> and in any case they are NOT going to FTP it, they want it to be
> embeddable in their own site, they'd like to see thumbnails, they want
> comments, they want to see how many people have viewed it, and so on.
> 
> The disadvantages to plone and drupal are real, and we need to discuss
> them. However, I think there is general agreement that we have got to
> move towards systems that have wider communities of developers, because
> coding our own shit has become unsustainable. In the long run, we need
> to work with others.
> 
> 3. Indymedia Player (Miro). This isn't a Miro 'fork,' don't worry ;)
> Miro developers announced a little while ago that they will partner with
> selected video producers to create preconfigured versions of Miro. All
> this means is 1. making an Indymedia skin for the player (a little bit
> of graphic design work) and 2. putting together a list of active
> Indymedia video feeds, which will come as the 'preset' channels in our
> 'version' of Miro. There is zero, repeat, zero coding needed for this
> project, we just give them an IMC skin and list of IMC video RSS feeds.
>  We need the list of active feeds anyway if we want to be able to
> provide aggregated IMC video content feed in various ways.
> 
> OK thanks for stimulating this conversation to move forward. It would be
> great if we could build on the push from TJ to get the current version
> of video.indy back up and running ASAP!
> 
> peace
> schock
> 
> 
> 
> 
> TJ wrote:
> > Hi,
> > 
> >> One, the current site has upload disabled, and none of the current
> >> site admins has responded to the hosting offers you mention.
> > 
> > uhmm, there were some very nice offers, I think it would be important
> > to at least answer them! If there is currently nobody having time for
> > communication via email, a quick call could do it also. I could
> > connect with the "swiss guys", as my native language is german and
> > swiss people usually speak german (kind of ;).
> > 
> >> We had come to agreement that we would set up test installs of these
> >> two CMS customized for video. We're gonna play with these for a bit,
> >> then decide which to go with for next gen video.indy.
> > 
> > VERY good to read "we will test" and not "we will use"...
> > 
> > I checked out both, drupal and plone, a while ago on a local machine,
> > I know drupal better than plumi, and I have a rough understanding for
> > what plone and zope are - both are interesting solutions with
> > advantages and disadvantages.
> > 
> > But, of course, NONE of the two qualify for a high-traffic site as
> > there is repetitive execution of code for things that could easily be
> > done with static content.
> > 
> > Plone is really heavy-weight and brings mucho very sophisticated
> > groupware basics and is in fact a very well designed software, a
> > master piece, that comes at a prize - performance. there are some
> > standard tuning procedures with plone - I am no expert with this - but
> > at least it is still very demanding for ressources.
> > 
> > Drupal is a hack, no question about that, but an interesting hack
> > ("Everything is a node - well, user profiles ar not..."). It can be
> > quite fast, but for a high traffic site you would like to spend some
> > time optimizing it?s database access - e.g. the URL ALIAS solution
> > does so many unneccessary sql queries on every request, it will hurt
> > server performance very hard when there is a real demand for the site.
> > Also if you put some modules into it to gain at least a little bit of
> > "group working together" features and to get a little bit into the
> > direction of what comes with plumi out of the box, like the OG
> > Modules, sql gets even wilder and putting together several modules can
> > lead to serious research activity. With not optimized code, PHP5 (not
> > 4 )and MYSQL5 (not 4 or 3), it alltogether can take as much ressources
> > as plumi.
> > 
> > I am not at the end of testing, of course both systems can be heavily
> > tuned and optimized, there are several caching solutions for both of
> > them.
> > 
> > BUT: Why do you need a CMS for a video download hub?
> > 
> > I am still a friend of POH (Plain old HTML) for really high traffic
> > sites. I ask people, who want a cms: "Why do you need a cms? Which
> > part of your site is that dynamic, that you need to regenerate it on
> > every request?"
> > 
> > If you want easy content creation, there are several ways to achieve
> > that. If you need users to login and do something, that not everybody
> > can do, there are several ways to do it. A combination of a CMS as a
> > frontend for content creators that will generate static content and
> > push this on a download server might be a good compromise.
> > 
> > So what is the demand for video.indymedia.org? Easy of use? latest
> > web-2.0 features? AJAX? Or maximum speed with minimal ressources?
> > 
> > Also very important, often forgotten: static content is easy to handle
> > - no database to backup across several servers, no inconsistency on a
> > fallback situation, no problems with different server environments
> > (php version, modules, missing python stuff, plone 2.5 stuff not
> > working with 3.0 and so on) - you just need a cheapo ftp login, rsync
> > and that?s it. Even better: you get "high availabilty" with some
> > simple additional DNS A records ("round robin") and can use new
> > servers around the world very fast.
> > 
> > it is very important to keep a "maximum simplicity" paradigm if you do
> > not have unlimited ressources of php or python programmers at hands
> > for a project. It can take months to understand a complex CMS even if
> > you know the underlying programming environment - with static content
> > and simple tools like ftp every child is able to maintain a site and
> > perform important tasks like "backup and restore" and the team can
> > focus on more important things like fundraising, organizing more
> > webspace and traffic and producing content.
> > 
> > "No CMS" does not mean that it is not possible to help people put up
> > information easy - there can be a simple form to describe an ftp
> > upload. Also, what is bad with the traditional method of using a
> > simple file "descrition.txt" within an FTP upload folder? That file
> > can be read out easily by a script and turned into html for each
> > video. It will be more easy than uploading through a web-frontend -
> > did you ever try to upload 500 Files through a web frontend? And right
> > now, how many people are able to write a mass import script for
> > drupal or plumi?
> > 
> > Do not misunderstand me - plumi and drupal and many, many other cms
> > solutions are great, a lot of work has been put into these, I do not
> > want to make them bad. They may be great solutions for a local group
> > with high demands for organizing themselves via internet and a need
> > for groupware-like functionality for a limited number of users.
> > 
> > But I think it will be a terrible design error putting one of these as
> > a bottleneck in front of "THE" world central video hub for alternative
> > media. Do not do it!!!
> > 
> > I could not find the specs for the video site (where are these?), but
> > if you urgently need some user login functionality and want people to
> > comment (why? to spend yout valuable time fighting spammers?), a P2P
> > enabled board-system might be another alternative to evaluate - there
> > is some good board-soft out there and "high-speed" is a design goal
> > for this kind of software since ever! (I like onebigtorrent.org)
> > 
> > Anyway, as I understand (I might be wrong here) the central, most
> > important task of video.indymedia.org is to distribute videos - we
> > do not need a CMS for that.
> > 
> > [Searching? Google will do! or use swish-e to serach the static
> > content? categorization? tags? menus? A script can generate that on
> > uploaded description files, after review of course.]
> > 
> > One more important point: security. NOTHING can beat static content in
> > that field. No explanation needed here.
> > 
> > My 2 cents on your CMS evaluation process. I hope, you will take your
> > time to check out every detail and rethink every aspect twice. I might
> > be able to help with whatever solution you come up with, but will not
> > try to convince anybody - this was my one and only comment on the
> > issue (nobody asked for ;)
> > 
> >> TJ, would you like to set up a Plumi (Plone) sandbox?
> > 
> > As I understand engagemedia.org itself IS the plumi sandbox. I setup
> > one on a local machine - I found no way of mass importing videos and
> > bittorrent support is still quite experimental. I have one debian
> > vserver "laying around" and I can try to install it there - AFTER the
> > video site is up again.
> > 
> >> Meanwhile, there is also an effort to create a list of all working
> >> video feeds from IMCs, to use to create a custom Miro player
> >> (formerly Democracy Player). Maybe anna is coordinating that?
> > 
> > Ummm, so they are really so many programmers around that indymedia can
> > afford working on a custom miro player - while video.indymedia.org is
> > down??? Why are you forking the miro player? Are you aware what
> > megaload of work you are putting on you??? Or is there a brilliant
> > genius-programmer who can do it in in one day? What happens, if that
> > guy disappears? Will you have another very long downtime AND a not
> > working player then?
> > 
> > Wouldn?t it be more important to get the video site up again ASAP???
> > 
> > Please don?t get me wrong - I am offering my help because I got the
> > impression, that there is a serious lack in human ressources right now
> > at indymedia - I am NOT a guy who has too many time, no son of
> > millionaire or sort of, and it will be a personal "sacrifice" of time
> > as I will have to cut other activities to help out here - that?s why I
> > am a little bit concerned about WHAT exactly I am doing ;)
> > 
> > ATM I would like to help to get the video.indymedia.org site online
> > again. Tell me, what is needed, to get the site online - I am sure,
> > this can be done right NOW WITHOUT plumi or drupal. It was running
> > before - so if it is "only" a webspace and traffic bottleneck, that
> > keeps the site down right now, I would like to focus on a solution for
> > exactly THAT right now - testing drupal and plumi can take MONTHS and
> > you do not want to keep the site down for several months, will you?
> > 
> > Will a 500GB dreamhost account do? That could be done TODAY, as a fast
> > help good enough - meanwhile I could start talking to the swiss guys
> > and ask other contacts to help out. FTP ACCESS is all I need right
> > now, who is responsible for adding or changing DNS records after
> > setting up some webspace? Some additional A records may be totally
> > sufficient for a quick solution ("round robin") to get the site up
> > again NOW.
> > 
> > Thanks for your attention.
> > 
> > Have a nice day,
> > Tomas Juriga
> > Elektronische Produktion
> > Tel: +49-211-6008150
> > 
> > _______________________________________________
> > imc-video mailing list
> > imc-video at lists.indymedia.org
> > http://lists.indymedia.org/mailman/listinfo/imc-video
> > 
> _______________________________________________
> imc-video mailing list
> imc-video at lists.indymedia.org
> http://lists.indymedia.org/mailman/listinfo/imc-video