imc blueprint techmeet world
 
Personal tools

DesignInspiration

From techmeet

Jump to: navigation, search

This page gives some more information about the architecture we are pursuing and the inspiration behind it!

Mambo -is- going to refactor their codebase using CakePHP. The only question is how soon are they going to do it and does that fit into our accelerated timetable (I'll have an answer later tonight).

Cake gives you the rapid app development model, MVC, a system which allows you to reuse cool features developed by the enormous CakePHP developers community (via helpers, extensions, etc), active records, scaffolding, ACL, etc. It isn't a port of Ruby on Rails, per se, but it uses a lot of the same concepts except it is built on a language (PHP) that is proven to scale, is more accessible and has a much larger developer pool, which is important for volunteer projects that are starved for help.

Our proposed architecture at http://dev.bunke.indymedia.org/ would have distributed servers all over the world that would be one of three types: 1) a webserver running the Cake app, 2) a middle tier running ICE and 3) some form of distributed MySQL. We could have packages that people can download, install and within 15 minutes start contributing to the distributed network as one of the servers.

The idea, then, is that the days of having traditional servers running individual IMC's would be replaced by a distributed network of servers, all of them running all of the IMC's. It solves our problem of server seizure by law enforcement, server loss due to hardware failure and donation withdrawals (like ahimsa). Basically, anyone with a static IP and a *nix box could become a node in this distributed network and the loss of any given node wouldn't be a big deal.

Our goals are to: 1) use technologies that have enormous developer communities outside of the IMC/activist world and 2) eliminate the old model of "x.indymedia.org is running on this server, go to them for help" -- a model which has proved to be extraordinarily burdensome for the people who end up being responsible for the codebases and the server administration.

I think the proposed architecture is pretty clever and would be the necessary catalyst for Indymedia to once again surpass our corporate competition, something that I'm personally committed to seeing through, having invested 8 years of my life to this project and watching in fear as it stagnates into a feature-less, half-assed network of blogs.

If you agree, you can help out in a lot of ways that don't involve too much commitment: help us find volunteers or help us build momentum by talking to people about the imc-cms/techmeet project and getting behind a revitalization of indymedia innovation. -ryan


There's been a lot of progress in the last couple months on the imc-cms front and with Techmeet 2008 approaching, I would imagine that we'll have a working prototype within the next 6-8 weeks. And, when I say prototype, I don't just mean a site with some improvements ... I mean the full-on, hyper-advanced architecture that we've designed that would forever solve the problems of server seizures, hardware failures and donation withdrawals (the types of problems that created enormous labor burdens on the sysadmin groups for mir and sf-active in 2007).

In fact, that part of the prototype is already up and running, thanks to work by Occam and Toya.

Yossarian has been building out an example front-end using Ruby on Rails, although we all agree that Ruby on Rails can't be used for the final product because of the well-known scalability problems and significantly smaller volunteer developer pool.

So, we've got some database configuration stuff to work out. And, we've got some of the front-end stuff to work out. And then we'll be really close to launching something. I've been meaning to write you an update e-mail for a while but I'm literally busy from 6AM to 9-10PM every day, for my work and then also running SFCCP, Linefeed and etc.

I figure now would be a good time to check in and see where imc-alternatives is at. I saw some posts from Sheri on the lists and I had spoken with her some months back, so I'm cc'ing her on this e-mail as well.

We're -really- excited about the new architecture -- not only will it drastically reduce the labor burden on just a few people but it will enable almost -anyone- to become a "node" in the distributed network. All that's required is a Linux/FreeBSD/*nix box and a static IP and you can help out! Most ISP's offer a static IP for only $20-$40 extra a month. We envision packages for each OS type that anyone can download, auto-install, and within minutes they become a part of the distributed network. We could literally have hundreds of nodes in the network, all geographically-dispersed, and if they fall offline for whatever reason, it won't matter. The network will figure it out and keep on going.

Another tech requirement we've had from the beginning is the use of non-IMC free software projects which already have enormous developer communities. From our experience, we've lived through attempts to make software that's only for IMC/activists and this has repeatedly created situations where a few people get burdened with working on the code which leads to stagnation. So, we've been very careful to select technologies which already have large, vibrant development communities outside of IMC.

Also, with this model, software upgrades can be propagated through the network, selectively added by each individual IMC via the admin interface. Furthermore, it enables "user sharing" -- IMCs who choose to participate can be part of a shared userbase so that someone who registered their nick on nyc.indymedia.org can also login to germany.indymedia.org -- using the same username/password, with a profile page that lists all the articles/media they've ever contributed on any IMC. We can probably even make this retroactive -- so users can go through a process that lets them add media from the past 8 years to their 'profile'.

Those of us sysadmins and programmers who have been so busy putting out fires and maintaining these isolated boxes every single day for 8 years now will be able to shift our time to more useful tasks -- monitoring the health of the distributed network and building new features for the front-end that make Flickr look out-of-date. For instance, we've been migrating Latin American IMC's from "stray" to "bunke" but not all of them had been moved and while "bunke" is an amazing machine that can handle it all and more, "stray" went down once every 24-48 hours. Either me or Toya or someone from SF then had to walk over to the colo and reboot it, or IMC's are down. This had been going on -REALLY- every 24-48 hours for about 4 months now. Needless to say, people like Occam, Zapata, Bart, Mat, Toya, me are MORE than ready for a lifestyle change (although, that particular migration is now over thanks to help from acracia from argentina/netherlands).

Anyway, that's an update from the imc-cms front. Basically, there have been little subgroups working on different pieces and we're just about ready to have a functioning prototype. The goal is to have a functioning prototype -before- Techmeet 2008, so that we can use that time to work on it and also figure out what remains to be done to get us into a public beta. If you look at http://dev.bunke.indymedia.org/ there are a number of IMC's who have volunteered to participate in the prototype.. SF, Denmark, London, and potentially a new imc coming together in Brazil's federation of IMC's.

I haven't had time to totally read up everything on imc-alternatives list but it looks like there is a design prototype coming together? That could be helpful to us because while we have some really great designers who have volunteered (Frederico, for example, who designed cmi-brasil's current site), it would be good to have something immediate. Any other updates you could give me (similar to this email) would be really helpful, and we can touch base again and see where there are points of collaboration. I think we're close to overcoming our corporate competition once again!!