Re: PHP 4.0.5 Release & Midgard Problems

On Fri, Mar 30, 2001 at 01:27:11PM -0500, Sterling Hughes wrote: > On Fri, 30 Mar 2001, James Moore wrote: > > > > Ummmmm... > > > > > > If I'm not mistaken, the midgaurd extension itself, only provides > > > functionality to the "midguard" application? Ie, end-users of midguard > > > will not use the functions and classes exported by the extension, only > > > midguard will use that functionality? > > > > > > If so, I'm not too sure it would be a good idea to include the midguard > > > extension in PEAR either... > > > > There is nothing stopping someone else making a php app that uses midguard > > extension if they want to. > Right, but from what I understand the functions only make sense for the > midguard application. Please clarify what you are understanding under term "midgard application"? Going this way anybody could say that MySQL extension only make sense for MySQL applications, IRCG -- for IRCG applications (no offense for Sascha :) and so on. Yes, Midgard provides different approach to store and process information than, f.g. MySQL extension, but it simply difference at high level. People are using Midgard together with other extensions as well, f.g. PostgreSQL, IRCG, ming, etc. and nobody said that Midgard functions only make sense for Midgard application. It is matter of proper design of application. > > I can see your point but if there is a feeling that it should be > > distributed with PHP in someway PEAR seems the most logical place. By your > > arugment why should midguard be in ext/ either as noone but people running > > midgard use it. PEAR is somewhere where it would be easy to retive from > > (eventually) and is hopefully where we will eventually have other non > > standard extensions. > > > > Yes, and no offense intended, I don't see why the midguard people don't > just distribute the extension *with* midguard. I could see some sense in We did it for years with prepatched PHP 3.x. It always caused problems with both PHP team and end users (former was not in favor in having another PHP3 version which was extended in the core, latter were unable to use Midgard without recompiling PHP3). We spent thousand of hours to make possible co-existance of Midgard and original PHP core engine (PHP3 in first, Zend Engine in second), did it, got big experience in template generation, found zillion bugs in both PHP versions (most of them were fixed during this process). One thing that we would not to do is to close this experience inside our product. Instead, we are trying to give away it for anybody in other projects too. PHP has no templating system at core and implementations in PHP itself are rather ineffective for high-loaded applications. I don't want to initiate additional flame here, please see the problem in open eyes. Ask Zend folks, they have our proposals, even C code to Zend engine to implement native templating with no connection to Midgard at all -- this system was designed to be generic for any template providers. Midgard could be one of these template providers, not exclusive one. It is some kind of extension like session but better because it also works with template providers instantiated from dynamically loaded modules. > distributing it with PHP, because then users of midguard really didn't > have to worry about compiling twice, etc, its already built-in to > php. While I'm not for that idea (it adds 70k of bloat), I don't see the > point in distributing it with PEAR. When you distribute it with pear > there is no advantage for the midguard people (or anyone) that I can see > (or advantage greater than just distributing the midguard extension with > midguard itself). We are really want to help PHP team to improve build environment and I'm personally did it in past month, look into archives. What is strange is that PHP team itself does not want to see problem with build environment as serious and continue talk about 'bloat' in code instead of productive work. It is sad. Please see this discussion as a call for collaborative discussion how to find solutions and improvements, not as an 'angry' answer. Latter is not productive in any movement, especially in Open Source. -- Sincerely yours, Alexander Bokovoy The Midgard Project | ALT Linux Team | Minsk Linux Users Group www.midgard-project.org | www.altlinux.ru | www.minsk-lug.net -- Since we're all here, we must not be all there. -- Bob "Mountain" Beck