On Wed, Mar 24, 2010 at 10:21 PM, Robert Cummings <rob...@interjinn.com> wrote:
> Rene Veerman wrote:
>> On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings <rob...@interjinn.com>
>> wrote:
>>> Rene Veerman wrote:
>>>> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings <rob...@interjinn.com>
>>>> wrote:
>>>>> Rene Veerman wrote:
>>>>>> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings
>>>>>> <rob...@interjinn.com>
>>>>>> wrote:
>>>>>>> Rene Veerman wrote:
>>>>>>>> php is not a hammer, its a programming language.
>>>>>>> It's hard to discuss anything with someone who doesn't comprehend a
>>>>>>> metaphor.
>>>>>> haha. "comprehend". you mean "accept".
>>>>>> that metaphor is stretched to breaking point as far as i'm concerned.
>>>>>>>> one that i feel needs to stay ahead of the computing trend if it is
>>>>>>>> to
>>>>>>>> be considered a language for large scale applications.
>>>>>>> Personification of PHP doesn't make your argument any more salient.
>>>>>>> PHP
>>>>>>> isn't trying to stay ahead of anything. People are using it to solve
>>>>>>> problems, not to meet some phantom ideal of a "computing trend"
>>>>>>> threshold.
>>>>>>>> but you nay-sayers here have convinced me; i'll be shopping for
>>>>>>>> another language with which to serve my applications and the
>>>>>>>> weboutput
>>>>>>>> they produce..
>>>>>>>> thanks for opening my eyes and telling to abandon ship in time.
>>>>>>> Obviously we didn't open your eyes.
>>>>>> Well excuse me for not dumping 50-100k lines of my own cms code
>>>>>> instantly now that i realize that in order to scale it, i could really
>>>>>> use features like threading and shared memory.
>>>>> Actually, you are th eone suggesting dumping your code since you said
>>>>> you
>>>>> were jumping ship. Many of us suggested that your problems can almost
>>>>> certainly be mitigated without threading.
>>>> "almost certainly". at least you're acknowledging that you might be
>>>> wrong.
>>> I'm certianly not right all the time. once I thought I was but I was
>>> wrong.
>>>> take this example, sorry for the crosspost;
>>>> my main concern atm is my own cms (50-100k lines of my own); it's
>>>> graphics-heavy, does fairly complicated db based logic, and if it ever
>>>> is to be used for a site like facebook, it'll get large dataflows that
>>>> have to be distributed over the servers used to generate html and
>>>> accessoiries for end-users.
>>>> i've built a layer into it that caches the output of oft-used pages
>>>> (like articles and their comments).
>>>> but adding many comments / minute to an article would result in quite
>>>> a bit of overhead, to update the html for that page and distribute it
>>>> (fast enough) to the relevant servers.
>>>> i'm worried about php's single-threaded nature; each request has to
>>>> fetch html updated in the last few seconds, or generate it from a list
>>>> of comments. that's also a big query from a big table for every
>>>> end-user.. :(
>>>> i'd rather keep them comments for an article in shared memory.....
>>> I think you'll find when you get even close to the size of facebook,
>>> everything you think you know now about how it all stays running will be
>>> thrown out the window. But then, I'm not a fan of early optimization of
>>> this
>>> magnitude. A good design is usually flexible enough to allow redesign
>>> without recoding everything. Baby steps to the moon IMHO.
>> yea, well, if i'm going to keep using php i need a path towards
>> scalability, for this particular problem.
>> i'd like to code the kinds of applications with big dataflows.
>> call me a golddigger all you want, it's what i am ;)
>> just not in the sexual sense hehe..
>>> Your tools are up to date. Threading is in the future if at all... it's
>>> certainly not in the present.
>> True, lets _keep_ 'm up-to-date, please.
> It is up to date. You mean make it have all the features you want. PHP is by
> it's very existence and ongoing development "up to date".

yet you seem to oppose said development into the threading/shared-mem corner.

without giving an alternative way to implement my previous case
description (facebook/twitter level commenting to graphics-heavy pages
at busy times).

and that's just 1 case description. hundreds if not thousands more can
be thought up or simply the best solution in the near future.

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to