Re: [PHP4BETA] What is ext/lcg/lcg.c?

On Mon, Aug 30, 1999 at 06:55:21AM +0200, Zeev Suraski wrote: > At 22:57 29/08/99 , Rasmus Lerdorf wrote: > > > > Uhh, I have an almost working tarball here. With a bit of hacking it is > > > > serving pages pretty reliably. I wouldn't say it is years away. > > > > > > I would. From the day you would be running it on your server, take at > > > least a year or two before you can even remotely call it mainstream. > > > >That may be, but we need a PHP module for it before it is released or we > >risk being seen as lagging behind and if other server-side languages are > >Apache2 compatible before us it will influence decision-making out there. > >Apache is our bread and butter. We have to be on the ball when it comes > >to anything related to Apache. You can't take a server with over 60% > >marketshare lightly. > > Apache 2.0 doesn't have even a single percent of market share, let alone > 60%. Apache 1.3.x has about 35 or 40, and Apache 1.2.x has about > 20-25. As such, it'll be a long while before Apache 2.x is our bread and > butter, if it ever catches through. > > My point here is that we must not rely on Apache 2.0 hooks to implement > anything in our architecture, because Apache 2.0 isn't something our users > are likely to use in the next few years. "We should take Apache 2 into account." That does not mean that we should _depend_ on A2 which is implied by you. It refers to the design process - if we avoid steps which make it hard to interact with A2, then we "take A2 into account." And, put the discussion about whether A2 is around the corner or not by side, at some point in time we will have to deal with it. My intention is therefore focused on avoiding mistakes, rather than planting A2 specific hooks into SAPI. > Did we (I) get carried away off the subject? Perhaps. I don't mind seeing > these SAPI startup/shutdown functions introduced. What I do mind is an > introduction of a programming methodology that's not portable. Perhaps the > session module is unique (and popular) enough to contain platform specific > code & architecture. In general, though, we should not encourage platform > specific code even if it features slight improvements here or there. The session module isn't platform specific nor does it contain platform specific code. It just happens to be faster for sites which use shared memory to store the session data. Once you port mm to platform X, the session module will be able to use shared memory there. -- Regards, Sascha Schumann Consultant