StatusNet is outputing XML without buffering.
It's OK when we want to make a dump, as the file may be huge, but the internal workflow is a bit tricky.
Let's say we want to write the rendering time in the HEAD of the document... How could we do this?
So I suggest to use DOM objects instead of writing directly into the output stream.
If you want buffering, there are functions built into PHP for that.
Is there a good reason to put the rendering time in the HEAD element? Is there an RFC that describes such a feature with good adoption rates in analysis software?
HTML is not just text. It is a text that handle the representation of a generic Model: DOM
When HTML is interpreted by a browser, it is transformed in DOM objects...
So, handling HTML only by manipulating plain text strings instead of dealing with models may introduce a gap between what the server-side developer is expecting to send to the client, and what it is really sent to the client. It is a bad practice that many web developers do since too much time.
The question of the rendering time was just a sample. You can make your own if you think about it a least 5 minutes.
Actually it's working for any data of the head which depends on the final document body, and it's working also for any data of the document which need to be filtered before outputting the result. (in a good MVC architecture, filtering is not part of controllers, so it may be applied after controllers output)
By the way, using DOM provides two other benefits:
Granted there are benefits to using the DOM (I don't argue with that), but how's the time vs. result ratio? :)
Given other issues, such as the dependency on legacy library PEAR::DB, the current codebase should mainly be maintained and not plain rewritten and eventually replaced with something else that can talk OStatus and render websites.
(one benefit of using DOM stuff would be to more easily just dump an Atom feed or activitystream object into the output, for example I'd love to be able to use raw XML to markup the page, so people could use their own XSLs to render stuff :])
But I personally feel like marking this as a WONTFIX if noone volunteers for patching :]
Using raw XML to markup the page, then transform it into HTML, is according to me, a good idea.
I already tested such concept here: http://xul.ccoste.fr/layout.xml (just have a look at the source code... )
First benefit is that we can cache XML instead of HTML and reuse this cache for HTML rendering AND for other type of views (like Atom, and so on)
An other benefit is to be able to handle themes without merging several CSS or javascript. Merging CSS and Javascript from several plugins is bad! How are we supposed to debug it? StatusNet should have only one global CSS file.
By the way.. StatusNet should provide the ability for plugin writers to just comply on an XML internal format which could be rendered afterward by the system.
Exemple:
<plugin-result name="plugin_1"><actions><action name="dothis" /><action name="dothat"></actions></plugin-result> <plugin-result name="plugin_2"><actions><action name="doSomething" /></actions></plugin-result> ...
We could get this from all plugins, then merge, into :
<result><actions><actions><action name="dothis" /><action name="dothat"><actions><action name="doSomething" /></action></result>
Then pre-process the interface:
<page><menu><item>doThis</item><item>doThat</item><item>doSomething</item></menu></page>
Then transform it to:
<html><body><ul class="menu"><li>doThis</li><li>doThat</li><li>doSomething</li></ul></body></html>
Each step can be cached, so we only process rendering and save database queries...
How many I/O do you think this could save, compared to what we have got for now?
I can say at least that some of the upcoming patches are made to handle more XML internally. (The Notice class will be able to receive an Activity object, which is parsed from XML)
And as mentioned, this would probably be something useful for a complete rewrite of the software rather than a modification to existing code. :]