This is incorrect. Sending semantic XML is cheaper over the long run than fully decorated HTML; the XSLT is cached and you'll save both server memory and cycles because you're constructing only the XML document instead of building the entire HTML structure every time.
I'll agree it's possible, but not certain, you'll get a saving in the XML weight. Writing HTML vs XML in the output is of limited difference as you will have to do the same processing so you know what data is required for the page so I think the processing and memory will be similar. If you don't process it then you'll have to send more data because it could be potentially needed by the system.
Of course if the client only requested the blocks of data it knew it needed then you could shift processing that way but then your more into the whole client side scripting aspect which is slightly off topic.
The overhead on high load server tends towards cycles (or memory if you have heavy cache strategies in place) rarely bandwidth, and if you have your scaling done correctly then your bottle neck is database writes, which leads to the need for either document databases rather than relational ones or smart sharding schemes which is again off topic. Of course less bandwidth use is always good as you can get faster response times and we can only wait and see if that is the case here.
I'd be happy to give the CMS a try though.
Only thing I'd worry about is performance. Does PHP's XML library use C under the hood?
It does
not that it matters in this case. Most extensions, and the core of the language are c based, also once you start using things like APC you have very little overhead from interpreting the PHP while the cache stays warm.
Author
Topic: XMLCMS (Read 1968 times)