[imc-cms] Observing, comments, etc re: CMS + Techmeet + Malandro

Gloria W strangest at comcast.net
Sat Jul 26 17:24:10 PDT 2008


Hi, I'm Gloria, I've been observing and helping Occam on the side when I 
can.

I wish I were not so busy, but I have three jobs currently, and cannot 
work on this project. I wish I could.
A bit about me: I have been doing *NIX embedded systems, application 
layer, and web development for 20+ years. I started in high school, on a 
MINIX system running on a IBM XT. Over the years, with most of my 
freelance and full-time work, I have written many different apps, from 
the db schema all the way up to the front end. My strongest development 
knowledge in in the back end "engine" and protocol layers.

The CMS model needed here is so unique that it really piqued my 
curiosity several months ago. Since then, I've been looking at every web 
based framework and protocol from this perspective, wondering what would 
be the closest solution.

Based on what I've seen in the conversations, I'd like to propose a few 
things to consider:

(1) Thinking of the "push" engine as a separate entity from the 
framework. It would be triggered by the framework, and could respond 
with it, but would not be tightly bound to the framework.

(2) Thinking of this system as a transaction based system. There would 
be four types of general transactions:
    (a) Push the framework to another host
    (b) Push the current content in bulk to another host
    (c) Push individual changes as small transactions, as a live synch 
between hosts
    (d) Administrative messages-commands sent-received and ACKed.

(3) The engine should be able to speak multiple protocols: XMPP, JSON, 
XML (if needed), etc. The protocol should be able to be dynamically 
selected by the transport layer portion of the engine, and should not be 
tightly bound to the model or the engine. For example, if the engine 
needs to clandestinely pass data to another host, it may use the SIP 
protocol to hide data in it's messages, and therefore not being detected.

(4) The encryption layer should be yet another independent layer in the 
engine, again standalone, dynamically configured by an admin transaction 
(d), and able to be applied to any/all/none of the transaction types 
listed above (a-d) at any time.

(5) The front end can be anything, any framework, any language, it does 
not matter. As long as it constructs the four transactions above, in the 
agreed upon formats, it can be used. Nothing else matters, no language 
wars or framework wars need to take place. The engine portions 1 through 
4 handle the propagation of the content, and do not dictate the content 
in any way.

So, 1 through 4 define the push engine, and 5 loosely encompasses any 
content.

Now, what tools to use for this "push" transactional engine? I would 
really recommend Kamaelia:
http://kamaelia.sourceforge.net/Home

This is written in Python, but since the push engine does not dictate 
your framework, this should be unimportant to content people.
Kamaelia is a really nice snap-together protocol-level framework which 
already speaks many protocols. The BBC paid for it's development, so 
that it could keep content in synch via many protocols. I think 
Indymedia has a similar problem, with additional legal caveats of 
course, and this tool would be useful.

I hope this inspires. Kamaelia is an inspiring engine with great promise.

Gloria





> Hi,
>
> it would be cool if ryan, Zapata and me could make some short summary  
> at techmeet08, to bring everyone up to date about the development and  
> ideas of the new-cms project.
>
> Also, i would like to do allot of brain storming about malandro and  
> all the details about a possible structure of the CMS.
>
> There are a couple of major problems where we need some solutions.
>
> a.) rsync replacement
>
> We need a *push based* solution to be able to distribute our content  
> changes as fast as possible.
>
> Ideas are: WebDAV. (A static mirror then would only need mod_ssi and  
> mod_webdav and a proper VirtualHost Config).
>
> b.) Middle-Size File Transport between Servers
>
> All the images and every kind of file up to 5-10MB. They are too huge  
> to transport as ICE-Objects, it would only slow down the ICE Layer.  
> Ideas: Also WebDAV, but does it support a resume?!?. Anyway, WebDAV  
> has something like "ls -al" which should help to implement this.
>
> c.) Frontend language
>
> There is one problem with the flexible server setup i proposed for  
> Malandro here:
> http://cyberpunk.cl/malandro/
>
> If you run a single-server setup where you would not need ice, you  
> run into the problem that you have to stick with one language. It  
> would not be possible to run PHP as Frontend and Python as backend.
>
> Why is that so?
>
> Well, ICE works by making a abstraction of your Objects and  
> Functions, and it is hard to share the same objects and functions  
> between PHP and Python. (ICE makes a Serialization of the Functions  
> and Objects).
>
> Also, it is not possible to use PHP as ICE Server, so if we stick  
> with one Language and ICE, it can be Python, Ruby, Java or C(++). Any  
> Votes? ;-)
>
> Before we start fighting: Any alternatives?
>
> d.) Alternative to ICE
>
> It would also possible to make a distribution network with a  
> combination of XMPP (Jabber) as transport, and Atom as representation  
> of the resources (article, content). This would allow a much more  
> open network without the limitations of ICE.
>
> The downside of this idea is the overhead of work you have to do.
>
> In ICE you make
>
> article = new IceArticle()	// this is nothing more then a empty class  
> that holds your article
> article.title = $POST['title']
> ice.server.publish(article)	// ice provides you with the  
> serialization of the data and the functions
>
>
> With XMPP you would need to make all the XML/Atom Overhead.
>
> article = new AtomArticle() // creates the Atom XML
> article.title = $POST['title']
> $xml = article.render_to_string();
> xmpp.connect()
> xmpp.send($xml);
>
> Did you noticed that this would only be the transport of the Article?  
> How do we tell the network that it has to delete a article? XMPP does  
> not have anything like ICE Interfaces to provide "network functions".
>
> Also, other RPC's like SOAP or XML-RPC don't have a Object  
> abstraction, you would have to serialize your objects or put anything  
> into parameters. (It is not possible to make server.publish(article)  
> with SOAP/XML-RCP, only server.publishArticle(title,content,etc))
>
> Whatever we use, the last and biggest question is
>
> e.) How does the CMS Structure look like.
>
> If we stick with the simplified "3 Tier Model" of Frontend, Publisher  
> and Backend
>
> - What Functions and Objects will each Tier Provide?
> - How will the Interfaces between the Tiers look like?
> - Where will ICE fit in best?
>
> http://cyberpunk.cl/malandro/struct.jpg
>
> This one shows where ICE could fit in.
>
> ICE as Publisher Interface:
> Pro:
>   - The publisher would have direct DB Access
> Contra:
>   - The publisher would have the only DB Access
>   - Very specific Fuctions. Any big feature change would require new  
> ICE Interfaces. This can be a version issue, where a Interface under  
> the same names works different in different Version.
>
> ICE as a Backend/DB Interface
> Pro:
>   - Simple Interface without any big changes since the DB Model will  
> not change that much
>   - Flexible
>   - Parts of the Dynamic Frontend could request objects directly.  
> (Even so, we DONT want that. The goals are autonomous Modules.
>
> Contra:
>   - Much more Traffic on the ICE Network
>   - Much more dependency on a working ICE Network
>
> Well, so far.
>
> Questions??
>
> I don't have any long years of experience with OO Models, Application  
> structures, and what is the best practice how to implement all of  
> this. So ANY feedback, ideas and thoughts are more then welcome.
>
> cya at techmeet08!
> occam
>
> _______________________________________________
> imc-cms mailing list
> imc-cms at lists.indymedia.org
> http://lists.indymedia.org/mailman/listinfo/imc-cms
>
>   



More information about the imc-cms mailing list