Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
On Mon, 02 Apr 2001, Alexander Bokovoy wrote: Andrei didn't use C coding in Smarty simply because his team failed to produce effective solution in reasonable time, but it does not mean that such solution impossible (no offense for IPSI at all, just facts from Smarty documentation). We have spent about three years for it and did such C-based template engine which proven to be fast and effective. Please, do not make rash assumptions about why or why not we made Smarty the way it is. There are enough bad assumptions in the world as it is. -Andrei * I don't have a solution but I admire the problem. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
On Mon, 02 Apr 2001, Andi Gutmans wrote: I very much liked Andrei's implementation of Smary templates. It uses the Zend (PHP) scripting language and caches templated scripts without messing with the core of PHP. Just nitpicking, Andi, but really, it's Zend that needs to be in parenthesis (if at all present), rather than PHP. That's the name of the language. -Andrei * The best source is the source code. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
PHP and midgard is still undergoing heavy development. Actually it's stable release went out a few days ago? - the midgard team actually aimed at matching the PHP release cycle.. - all modifications at present are pure bug fixes.. Sascha complains about the stability of PHP and all of our patch levels yet Rasmus wants to include these extensions that are applications in their own right, it just isn't practical for the QA team to test something the size of midgard and thus it doesn't get tested (unless the midgard folks test it which we have to presume doesn't happen as we get no feedback from them), we then risk getting to a point like this where we are about to release PHP 4.0.5 and it either 1) has to be delayed with another release cycle 2) has to continue with a broken midgarad, neither are great but for the QA team its very annoying when midgard, somewhat of an outside extension means we have to do a whole new cycle. We are one of the bigger application developers on midgard (having done nadmin http://www.hklc.com/midgard_manual), and also probably the bigger bug finder fixer - Midgard bugs are reported and fixed on it's own mailing list - outside of php-dev. (considering the traffic here - It helps everybody...) In terms classing midgard as an extension, it seems that it is no difference in terms of maintenance (QA etc.) to other extensions like ming, xml ... (great work there too..) the whole extenstion scheme works very well, however the line between 'core extension' and 'other extension', has and probably will continue to be vague. Interestingly, Our test builds of midgard are always done against packaged systems (arvins work on rpms - many kudos there). As the generally we need to install midgard into production enviroments. So it has been important to have midgard compile against earlier versions of PHP4 - from what we saw, the backwards compatibility issue has caused a few problems as the API in PHP4 gets modified slightly so it breaks this compatibility. I would urge the PHP development team to support midgard module (just by keeping it the core dist. under ext.) 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? Isnt that a bit like saying the XML module only provides functionallity to a XML application.. end users - use the midgard functions - we have almost completed a port of openmerchant to PHP4/midgard - it stores the templates and some trasent data in midgard datastore, along with the page's - it adds a level of security, reducing or removing the dependance of file system write access. Regards Alan Knowles P.S. Anybody fancy looking at the chinese htmlcharacters bug + patch :) If so, I'm not too sure it would be a good idea to include the midguard extension in PEAR either... -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
I very much liked Andrei's implementation of Smary templates. It uses the Zend (PHP) scripting language and caches templated scripts without messing with the core of PHP. I haven't used it but from reading the specs it looks like Andrei his guys did a great job. Andi At 11:10 AM 4/1/2001 +0300, Alexander Bokovoy wrote: On Sun, Apr 01, 2001 at 09:07:44AM +0200, Sebastian Bergmann wrote: Alexander Bokovoy wrote: 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. Does this have to be implemented in the ZendEngine or would a ext/template extension (for instance) be possible, also? This would be great, though Template Engines are a dying species with the advent of XSLT, IMHO. Not so simple because XSLT is far than complex for lot of applications and especially when you are trying to provide content edit capabilities for non-techies. This is huge nische. It most effective at ZendEngine level but actually task is two-tiered. Let me describe: 1. Templating require additional syntax which is better handled by ZendEngine 2. Syntax provides access to collection of template elements and manipulation of them. It's up to template provider to collect template elements from some source(s) before actual template building. This is better handled by extensions. This separation also allows to make complex transitions like 'document with template markup' - XML-based source + XSLT - output In this case second step is done by Template Provider which provides template elements + hooks to translate them to XML + output callbacks. Zend Engine dispatches these calls via easy user-oriented syntax. For example, in Midgard we have two kinds of template calls: [template element] -- just insert content of template element here and evaluate it as PHP code. It looks like hidden functional call to include() but the difference is that 'template element' actually can come from completely different place than file system (in Midgard it comes from Database or FileTemplates). (variable:formatter); -- pass $variable throught existing formatter and insert output into output stream. Different formatters allow to convert plain text to HTML with different levels of formatting, execute PHP code, execute user-defined formatter against $variable. Variable could be any PHP structure (scalar, object, array, etc) These are very simple constucts, but they are greatly reduce build-up for non-technical interfaces. -- 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 -- Success is in the minds of Fools. -- William Wrenshaw, 1578 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
On Mon, Apr 02, 2001 at 12:21:07AM +0200, Andi Gutmans wrote: I very much liked Andrei's implementation of Smary templates. It uses the Zend (PHP) scripting language and caches templated scripts without messing with the core of PHP. I haven't used it but from reading the specs it looks like Andrei his guys did a great job. Yes, I know about Smarty. Most important problems with it are: 1. It is file-oriented and does not respect templates from different non-filebased sources (RDMBS, inter-webserver module information exchange) 2. It does not support template overriding or hierarcies (i.e. subclassing of already existing style) These two problems render it unusable for RDBMS-based applications. In Midgard, for example, only bootstrap file with initial template is stored in filesystem (only because PHP3 did not support execution of non-filebased sources -- not so much changes in PHP4 too). All other information (pages, templates, template elements, content and so on) are in RDBMS. Andrei didn't use C coding in Smarty simply because his team failed to produce effective solution in reasonable time, but it does not mean that such solution impossible (no offense for IPSI at all, just facts from Smarty documentation). We have spent about three years for it and did such C-based template engine which proven to be fast and effective. Andi At 11:10 AM 4/1/2001 +0300, Alexander Bokovoy wrote: On Sun, Apr 01, 2001 at 09:07:44AM +0200, Sebastian Bergmann wrote: Alexander Bokovoy wrote: 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. Does this have to be implemented in the ZendEngine or would a ext/template extension (for instance) be possible, also? This would be great, though Template Engines are a dying species with the advent of XSLT, IMHO. Not so simple because XSLT is far than complex for lot of applications and especially when you are trying to provide content edit capabilities for non-techies. This is huge nische. It most effective at ZendEngine level but actually task is two-tiered. Let me describe: 1. Templating require additional syntax which is better handled by ZendEngine 2. Syntax provides access to collection of template elements and manipulation of them. It's up to template provider to collect template elements from some source(s) before actual template building. This is better handled by extensions. This separation also allows to make complex transitions like 'document with template markup' - XML-based source + XSLT - output In this case second step is done by Template Provider which provides template elements + hooks to translate them to XML + output callbacks. Zend Engine dispatches these calls via easy user-oriented syntax. For example, in Midgard we have two kinds of template calls: [template element] -- just insert content of template element here and evaluate it as PHP code. It looks like hidden functional call to include() but the difference is that 'template element' actually can come from completely different place than file system (in Midgard it comes from Database or FileTemplates). (variable:formatter); -- pass $variable throught existing formatter and insert output into output stream. Different formatters allow to convert plain text to HTML with different levels of formatting, execute PHP code, execute user-defined formatter against $variable. Variable could be any PHP structure (scalar, object, array, etc) These are very simple constucts, but they are greatly reduce build-up for non-technical interfaces. -- 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 -- Success is in the minds of Fools. -- William Wrenshaw, 1578 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- 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 -- If practice makes perfect, and nobody's perfect, why practice? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
As a user of PHP and Midgard, I'd just like to comment that my use of PHP is completely dependent on my perception of it's potential to embrace integrating applications like Midgard. I'd like to see Midgard do for PHP what Zope has done for Python in the way of increasing the level of penetration of the language. This won't happen unless it's easy to install a version of Midgard on top of a standard version of PHP. I love PHP, but generally I find the lack of applications such as Midgard a major disincentive to using it. I won't continue using it for long if this continues to be the case. It's already pretty tempting to drop it in favour of Java or Python. Paul N. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
I'd like to see Midgard do for PHP what Zope has done for Python in the way of increasing the level of penetration of the language. What exactly has zope done for Python? Nothing. The measurement of python's increased penetration as a result of zope can be expressed simply as 'zilch'. This won't happen unless it's easy to install a version of Midgard on top of a standard version of PHP. To suggest that the success of PHP relies on its ability to accommodate apps like midgard is like saying the success of html is directly dependent on, gulp, Dreamweaver. I love PHP, but generally I find the lack of applications such as Midgard a major disincentive to using it. I won't continue using it for long if this continues to be the case. It's already pretty tempting to drop it in favour of Java or Python. There's tons of stuff out there that can mimic midgard, opensource and otherwise. None of them require the level of integration midgard currently enjoys. At best, Midgard belongs in PEAR. It most definitely, IMHO, does not belong in the PHP source. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
As a user of PHP and Midgard, I'd just like to comment that my use of PHP is completely dependent on my perception of it's potential to embrace integrating applications like Midgard. I'd like to see Midgard do for PHP what Zope has done for Python in the way of increasing the level of penetration of the language. This won't happen unless it's easy to install a version of Midgard on top of a standard version of PHP. Is Zope distributed with Python? I think not. There is nothing stopping the midguard folks distributing the latest version of PHP compiled or as source code with midguard so people can go one place and download midguard or midguard can be placed in PEAR but midgard is too bigger project to have in PHP cvs for the two systems release cycles to coordinate well so both are stable at the same time. James -- James Moore [EMAIL PROTECTED] PHP Web Scripting: http://www.php.net/ PHP QA Team: http://qa.php.net/ PHP-GTK: http://gtk.php.net/ VL-SRM: http://www.vl-srm.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
On Sat, 31 Mar 2001, James Moore wrote: Is Zope distributed with Python? I think not. There is nothing stopping the midguard folks distributing the latest version of PHP compiled or as source code with midguard so people can go one place and download midguard or midguard can be placed in PEAR but midgard is too bigger project to have in PHP cvs for the two systems release cycles to coordinate well so both are stable at the same time. Just wanted to add my +1 on removing midgard from CVS. ;-) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
Alexander Bokovoy wrote: 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. Does this have to be implemented in the ZendEngine or would a ext/template extension (for instance) be possible, also? This would be great, though Template Engines are a dying species with the advent of XSLT, IMHO. -- sebastian bergmann[EMAIL PROTECTED] http://www.sebastian-bergmann.de bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
On Sun, Apr 01, 2001 at 09:07:44AM +0200, Sebastian Bergmann wrote: Alexander Bokovoy wrote: 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. Does this have to be implemented in the ZendEngine or would a ext/template extension (for instance) be possible, also? This would be great, though Template Engines are a dying species with the advent of XSLT, IMHO. Not so simple because XSLT is far than complex for lot of applications and especially when you are trying to provide content edit capabilities for non-techies. This is huge nische. It most effective at ZendEngine level but actually task is two-tiered. Let me describe: 1. Templating require additional syntax which is better handled by ZendEngine 2. Syntax provides access to collection of template elements and manipulation of them. It's up to template provider to collect template elements from some source(s) before actual template building. This is better handled by extensions. This separation also allows to make complex transitions like 'document with template markup' - XML-based source + XSLT - output In this case second step is done by Template Provider which provides template elements + hooks to translate them to XML + output callbacks. Zend Engine dispatches these calls via easy user-oriented syntax. For example, in Midgard we have two kinds of template calls: [template element] -- just insert content of template element here and evaluate it as PHP code. It looks like hidden functional call to include() but the difference is that 'template element' actually can come from completely different place than file system (in Midgard it comes from Database or FileTemplates). (variable:formatter); -- pass $variable throught existing formatter and insert output into output stream. Different formatters allow to convert plain text to HTML with different levels of formatting, execute PHP code, execute user-defined formatter against $variable. Variable could be any PHP structure (scalar, object, array, etc) These are very simple constucts, but they are greatly reduce build-up for non-technical interfaces. -- 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 -- Success is in the minds of Fools. -- William Wrenshaw, 1578 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
James Moore wrote: This will undoubtedly happen again and again ad midgard and PHP work on different release cycles and is by no means the fault of the midgard people but it just isn't practical if we are trying to release stable versions of PHP and midgard is still undergoing heavy development. True, but in this case the main issue is a problem in the autoconf system. I propose that we remove midgard from the PHP CVS into a separate PEARC module before the release of 4.0.5 so that midgard is never been included in a PHP release. It will give some incentive to get the PEARC system running sooner too. If nobody objects to this strongly I propose we do this in 24-48 hours and then release 4.0.5 which has been dragging on for a while now. Doesn't have my preference, of course, but if that's the general feel on php-dev then that's what needs to happen. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
James Moore wrote: Sascha complains about the stability of PHP and all of our patch And I think he is right about this. I propose that we remove midgard from the PHP CVS into a separate PEARC module Stig created such a module, called PEAR (who would've thought of that? *g*), some days ago. Currently it contains the C implementation of PEAR's base class. before the release of 4.0.5 so that midgard is never been included in a PHP release. +1 -- sebastian bergmann[EMAIL PROTECTED] http://www.sebastian-bergmann.de bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
IMHO, this sounds like its best for everyone, *especially* the end users of midgard and php. -Jason - Original Message - From: "James Moore" [EMAIL PROTECTED] To: "[EMAIL PROTECTED]" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 30, 2001 12:02 PM Subject: [PHP-DEV] PHP 4.0.5 Release Midgard Problems Sorry to bring this up yet again but before we release 4.0.5 this needs to be sorted otherwise nothing will ever happen. We have just reached 4.0.5RC4 (which was the final planned RC) and we find that the midgard folks need to fix some bugs with the build process. This will undoubtedly happen again and again ad midgard and PHP work on different release cycles and is by no means the fault of the midgard people but it just isn't practical if we are trying to release stable versions of PHP and midgard is still undergoing heavy development. Sascha complains about the stability of PHP and all of our patch levels yet Rasmus wants to include these extensions that are applications in their own right, it just isn't practical for the QA team to test something the size of midgard and thus it doesn't get tested (unless the midgard folks test it which we have to presume doesn't happen as we get no feedback from them), we then risk getting to a point like this where we are about to release PHP 4.0.5 and it either 1) has to be delayed with another release cycle 2) has to continue with a broken midgarad, neither are great but for the QA team its very annoying when midgard, somewhat of an outside extension means we have to do a whole new cycle. I propose that we remove midgard from the PHP CVS into a separate PEARC module before the release of 4.0.5 so that midgard is never been included in a PHP release. It will give some incentive to get the PEARC system running sooner too. If nobody objects to this strongly I propose we do this in 24-48 hours and then release 4.0.5 which has been dragging on for a while now. James -- James Moore [EMAIL PROTECTED] PHP Web Scripting: http://www.php.net/ PHP QA Team: http://qa.php.net/ PHP-GTK: http://gtk.php.net/ VL-SRM: http://www.vl-srm.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
On Fri, 30 Mar 2001, James Moore wrote: Sorry to bring this up yet again but before we release 4.0.5 this needs to be sorted otherwise nothing will ever happen. We have just reached 4.0.5RC4 (which was the final planned RC) and we find that the midgard folks need to fix some bugs with the build process. This will undoubtedly happen again and again ad midgard and PHP work on different release cycles and is by no means the fault of the midgard people but it just isn't practical if we are trying to release stable versions of PHP and midgard is still undergoing heavy development. Sascha complains about the stability of PHP and all of our patch levels yet Rasmus wants to include these extensions that are applications in their own right, it just isn't practical for the QA team to test something the size of midgard and thus it doesn't get tested (unless the midgard folks test it which we have to presume doesn't happen as we get no feedback from them), we then risk getting to a point like this where we are about to release PHP 4.0.5 and it either 1) has to be delayed with another release cycle 2) has to continue with a broken midgarad, neither are great but for the QA team its very annoying when midgard, somewhat of an outside extension means we have to do a whole new cycle. I propose that we remove midgard from the PHP CVS into a separate PEARC module before the release of 4.0.5 so that midgard is never been included in a PHP release. It will give some incentive to get the PEARC system running sooner too. If nobody objects to this strongly I propose we do this in 24-48 hours and then release 4.0.5 which has been dragging on for a while now. Um... 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... -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
Um... 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. 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. James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
On Fri, 30 Mar 2001, James Moore wrote: Um... 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. 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 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). -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 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: Um... 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
