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

[ryan]

Yes -- there is a prototype that was created at Techmeet 2008 which is a
big leap ahead of the project.

After Techmeet this year, a bunch of CMS programmers headed to Budapest
for the NODR conference which caused delays. Once this was over, there
was a major distraction caused by a proposal from the Riseup collective
which created a few weeks of unproductive argumentation, and just about
now, things are picking up again on imc-cms ... I wish the process was
going faster but we are also all balancing this with our lives. Feel
free to join imc-cms (even in digest mode) to keep up with the latest
updates, there is some renewed momentum going on right now
-ryan

Jay wrote:
> 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
> 
> _______________________________________________
> Imc-alternatives mailing list
> Imc-alternatives at lists.indymedia.org
> http://lists.indymedia.org/mailman/listinfo/imc-alternatives