[Imc-alternatives] Fwd: Re: [imc-cms] Next Gen CMS Archeticture

[Jay]

Some info about the new IMC cms.  Seems like there's a 
proof-of-concept code out there.

It's tech-heavy e-mail but may make sense to some.

Jay

>From: Occam <indymedia at gmail.com>
>
>Hi Ben,
>
>sorry for the late ansfer, but thanks for your message - its good to
>see, that you got the main idea.
>
>
> > The discussions in imc-tech have made me very interested in working
> > with imc-cms group to get the Indymedia 2.0, or whatever it should be
> > called, working and in use.   I took a look at the
> > imc-cms.indyarch.pdf files and have a couple questions for folks:
> >
> > 1) Is there a plan for getting all of this implemented?  If so, what
> > has happened so far?
>
>There is some proof of concept python code for the backend and some
>more bits and bytes for the frontend. Also hyperactive has a new
>approach for the frontend part. http://techmeet.org/txt/CMSFAQ is a
>good starting point.
>
>The Proof of concept code is here: https://codecoop.org/scm/?
>group_id=104
>
> >
> > 2) What is the idea behind the grid management tier?  What problems
> > does it solve that aren't handled by having a distributed database?
> >
>
>MySQL Replication is hard to do over long distant internet
>connections. The global character of indymedia makes a very decentral
>server network. This decentralisation is a "must have" for us, to get
>around the effects of repression against indymedia.
>
>The genereal idea is much more about fail-over, decentralisation, and
>autonomity(!) of the different modules of a CMS. It is not just about
>keeping the data save.
>
>We dont have a huge need to keep the site up at 99.9%, but we have a
>huge need to be able to move sites/modules from one server to another.
>
>Autonomity means that you seperate the functionality of a CMS over
>different servers. If one server is taken away, you lose - for
>example the "search" - but your still able to publish informations.
>Even if your hole "middle tear" is taken away, and you only have the
>DB and static files, you still can pass informations to the public
>with "vim index.shtml".
>
>Autonomity also means that things like the search should have all the
>informations they need in a local copy (NOT a cache, a cache is NOT
>autonom).
>
>Also, having very different servers, gives a huge need to a have a
>CMS that scales and is flexible.
>
> > The ones that I got from the PDF were pushing updates for the webapps,
> > having a IMC-wide messaging system and keeping track of the latest
> > post/latest comments.  Those things are pretty cool, but I don't see
> > why they couldn't be handled in a simpler way.  For example a single
> > server with a REST API or something.
> >
> > Is the idea that it would be some sort of ORM system or something?
>
>We had some talk about how to implement it. I personaly prefer to put
>the network layer at the "service" level and not down at the
>Database. So more like a RPC Interface with services. ICE is doing
>this very well. This also gives you a bit more security, since you
>can avoid any direct DB access.
>
>I never worked with REST, i dunno if its a possible solution. But,
>public "blog" API's like wordpress has, are things we need to provide
>on the frontend level.
>
> >
> > 3) Would servers in the static tier store all the static files in the
> > entire network?  If this is true, I would question if it is
> > possible/desirable to do this.  It seems like a huge amount of data to
> > me and sets a pretty high barrier to entry.
>
>All IMCs in the indymedia network work autonom and decide on there
>own what CMS they us. Some IMCs might just not have the need to use
>this new decentral CMS. Its very unlickly that we will end up with
>one huge big setup. It is not our goal to have one solution for
>everyone.
>
>However, it would be a good idea to allow the the "splitting" of the
>static content. The content type is the best starting point here.
>After that a year based seperation was very usefull in the past. If
>you have a setup like 2008.img.site.indymedia.org/2008/01/id.jpg,
>2007.audio.site.indymedia.org etc, you scale very well. Static shtml
>files dont take so much space and are very to easy handle. For large
>video files, you will need a seperated server and transport mechanism
>anyway.
>
>We already have this structure with the current Mir Producer (http://
>techmeet.org/txt/CMSProducer)
>
> >
> > 4) I have a lot of experience doing python web development (and python
> > develop in general) and pretty decent PHP experience.  Where can I
> > help?
> >
>
>Well, check out the proof of concept "malandro" code, its in python
>using ice. If you have trouble with the setup, come over to #cms on
>irc.indymedia.org or drop me a email. We also have a dev-server for
>malandro with a working running setup you can play with.
>
>We made the proof of concept code as a base and a start and to give
>developers something to play with, so they can see the idea.
>
>So, your very welcome to check it out :)
>
>occam
>_______________________________________________
>imc-cms mailing list
>imc-cms at lists.indymedia.org
>http://lists.indymedia.org/mailman/listinfo/imc-cms