<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: PHP Application server - GSoC proposal</title>
	<atom:link href="http://cesar.la/php-application-server-gsoc-proposal.html/feed" rel="self" type="application/rss+xml" />
	<link>http://cesar.la/php-application-server-gsoc-proposal.html</link>
	<description>From the Jungles of Paraguay</description>
	<pubDate>Tue, 07 Sep 2010 17:38:11 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: César Rodas</title>
		<link>http://cesar.la/php-application-server-gsoc-proposal.html/comment-page-1#comment-330</link>
		<dc:creator>César Rodas</dc:creator>
		<pubDate>Tue, 24 Mar 2009 17:38:02 +0000</pubDate>
		<guid isPermaLink="false">http://cesar.la/?p=185#comment-330</guid>
		<description>Just updated to the version 2 of this posts, thanks to Alex for the feedback.</description>
		<content:encoded><![CDATA[<p>Just updated to the version 2 of this posts, thanks to Alex for the feedback.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: César Rodas</title>
		<link>http://cesar.la/php-application-server-gsoc-proposal.html/comment-page-1#comment-328</link>
		<dc:creator>César Rodas</dc:creator>
		<pubDate>Mon, 23 Mar 2009 17:46:35 +0000</pubDate>
		<guid isPermaLink="false">http://cesar.la/?p=185#comment-328</guid>
		<description>Probably you are right, thanks for the guide.

I understand the basis about what your telling me, but I'm still convinced that way it's a good way to scale.

&gt;I also think that many see "C daemon with embeded PHP" and

&gt;wonder "So, what's mod_php inside Apache then?".

&gt;You don't explain that.

My idea it's separate the website, in services, i.e In you Apache (mod_php) you have basic routine to show the page, then you create an application and put on the Appserver (you write a service), called Register_User, from you Apache you can request the execution of that function, and it returns something, in this case true if success otherwise false.

If the Register_User function does a lot of things, perform a select over a sql table, find duplicated e-mail, validate all those data. The whole overhead it's perform in another server, and you mod_php waits the answer. Since the Apache will be idle waiting, it will be able to handle other request.

My idea it's not replace Apache, nor create a new kinda Webserver. My goal it's provide a way to distribute work over machines, in order to have small process on the front, and hard process on over machines. 

Additional my idea was added "procedures" and "functions", "functions" returns something, "procedures" does not (a.k.a Queue something for a late execution).

It is clear enough? 

P.S: Regard the comment edit, it is WP, not my fault this time ;).
P.S: Once again, thanks for you comment.</description>
		<content:encoded><![CDATA[<p>Probably you are right, thanks for the guide.</p>
<p>I understand the basis about what your telling me, but I&#8217;m still convinced that way it&#8217;s a good way to scale.</p>
<p>>I also think that many see &#8220;C daemon with embeded PHP&#8221; and</p>
<p>>wonder &#8220;So, what&#8217;s mod_php inside Apache then?&#8221;.</p>
<p>>You don&#8217;t explain that.</p>
<p>My idea it&#8217;s separate the website, in services, i.e In you Apache (mod_php) you have basic routine to show the page, then you create an application and put on the Appserver (you write a service), called Register_User, from you Apache you can request the execution of that function, and it returns something, in this case true if success otherwise false.</p>
<p>If the Register_User function does a lot of things, perform a select over a sql table, find duplicated e-mail, validate all those data. The whole overhead it&#8217;s perform in another server, and you mod_php waits the answer. Since the Apache will be idle waiting, it will be able to handle other request.</p>
<p>My idea it&#8217;s not replace Apache, nor create a new kinda Webserver. My goal it&#8217;s provide a way to distribute work over machines, in order to have small process on the front, and hard process on over machines. </p>
<p>Additional my idea was added &#8220;procedures&#8221; and &#8220;functions&#8221;, &#8220;functions&#8221; returns something, &#8220;procedures&#8221; does not (a.k.a Queue something for a late execution).</p>
<p>It is clear enough? </p>
<p>P.S: Regard the comment edit, it is WP, not my fault this time ;).<br />
P.S: Once again, thanks for you comment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Markus</title>
		<link>http://cesar.la/php-application-server-gsoc-proposal.html/comment-page-1#comment-327</link>
		<dc:creator>Markus</dc:creator>
		<pubDate>Mon, 23 Mar 2009 17:32:26 +0000</pubDate>
		<guid isPermaLink="false">http://cesar.la/?p=185#comment-327</guid>
		<description>No way to edit my comments. Oh my!

The last thing should read "I'm trying to stay neutral.".

And something to add about caching: HTTP caching is well known and well understood; just in case you're proposing a new cache technique which hasn't seen the light yet you've to explain why it's better to go from scratch.

If it's about performance, where are the performance savings.

Ok, I'll stop. I'm not the one to convince anyway. I'm just trying to write down what I think people visualize about your idea. I can be wrong, don't forget that :)</description>
		<content:encoded><![CDATA[<p>No way to edit my comments. Oh my!</p>
<p>The last thing should read &#8220;I&#8217;m trying to stay neutral.&#8221;.</p>
<p>And something to add about caching: HTTP caching is well known and well understood; just in case you&#8217;re proposing a new cache technique which hasn&#8217;t seen the light yet you&#8217;ve to explain why it&#8217;s better to go from scratch.</p>
<p>If it&#8217;s about performance, where are the performance savings.</p>
<p>Ok, I&#8217;ll stop. I&#8217;m not the one to convince anyway. I&#8217;m just trying to write down what I think people visualize about your idea. I can be wrong, don&#8217;t forget that <img src='http://cesar.la/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Markus</title>
		<link>http://cesar.la/php-application-server-gsoc-proposal.html/comment-page-1#comment-326</link>
		<dc:creator>Markus</dc:creator>
		<pubDate>Mon, 23 Mar 2009 17:26:55 +0000</pubDate>
		<guid isPermaLink="false">http://cesar.la/?p=185#comment-326</guid>
		<description>I've read your proposals on the list and I don't think it's your English. There's room for improvement, sure ;-), but I think people understand quite well what you're proposing and I think the very fundamental problem lies there in itself.

Some things ahead: if you explain "Some concepts" and provide a graph without labeling all of the concepts, it's confusing. Apply the Client/Worker terms into the graph.

I think people find it hard to grok the C-Daemon thing. You've just provided architectural concepts and the daemon "looks" heavy weight. Heavy things are not everyone friends. If it can be light-weight, provide some insights why and how.

I also think that many see "C daemon with embeded PHP" and wonder "So, what's mod_php inside Apache then?". You don't explain that.

Why can't a Worker be just a well-proven-tested-has-been-around-for-decades-apache-instance instead some proprietary-looking-from-scratch-written-and-thus-probably-bug-ridden daemon?

What interchange formats are you proposing?

Since the dawn of PHP4 in May 2000 there have been zillions approaches of App-Servers, Distributed Environments, Self-Running-Daemons and whatnot. None of them *really* succeeded.

Too complex for developers, too many bugs, looked fine on paper but didn't do well (in whatever aspect) when done, too hard to use, no useful documentation, support, etc.

So. I'm trying to stay object. For me this concept needs to be fleshed out better, thinking ahead.

Good luck! :-)</description>
		<content:encoded><![CDATA[<p>I&#8217;ve read your proposals on the list and I don&#8217;t think it&#8217;s your English. There&#8217;s room for improvement, sure ;-), but I think people understand quite well what you&#8217;re proposing and I think the very fundamental problem lies there in itself.</p>
<p>Some things ahead: if you explain &#8220;Some concepts&#8221; and provide a graph without labeling all of the concepts, it&#8217;s confusing. Apply the Client/Worker terms into the graph.</p>
<p>I think people find it hard to grok the C-Daemon thing. You&#8217;ve just provided architectural concepts and the daemon &#8220;looks&#8221; heavy weight. Heavy things are not everyone friends. If it can be light-weight, provide some insights why and how.</p>
<p>I also think that many see &#8220;C daemon with embeded PHP&#8221; and wonder &#8220;So, what&#8217;s mod_php inside Apache then?&#8221;. You don&#8217;t explain that.</p>
<p>Why can&#8217;t a Worker be just a well-proven-tested-has-been-around-for-decades-apache-instance instead some proprietary-looking-from-scratch-written-and-thus-probably-bug-ridden daemon?</p>
<p>What interchange formats are you proposing?</p>
<p>Since the dawn of PHP4 in May 2000 there have been zillions approaches of App-Servers, Distributed Environments, Self-Running-Daemons and whatnot. None of them *really* succeeded.</p>
<p>Too complex for developers, too many bugs, looked fine on paper but didn&#8217;t do well (in whatever aspect) when done, too hard to use, no useful documentation, support, etc.</p>
<p>So. I&#8217;m trying to stay object. For me this concept needs to be fleshed out better, thinking ahead.</p>
<p>Good luck! <img src='http://cesar.la/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
</channel>
</rss>
