On Wed, Mar 24, 2010 at 10:21 PM, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: > > > Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings <robert@xxxxxxxxxxxxx> >> wrote: >>> >>> Rene Veerman wrote: >>>> >>>> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings <robert@xxxxxxxxxxxxx> >>>> wrote: >>>>> >>>>> Rene Veerman wrote: >>>>>> >>>>>> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings >>>>>> <robert@xxxxxxxxxxxxx> >>>>>> 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