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 aga
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 devel
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 da
ch 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
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
> 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 i
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
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 u
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 penetrat
> 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'.
> 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
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
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 wou
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 templ
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 +0
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 l
Alex,
It's a lost cause. I went through this whole thing over a year ago and
I've still got burn marks to show for it.
On Sun, 01 Apr 2001, Alexander Bokovoy wrote:
> Not so simple because XSLT is far than complex for lot of applications and
> especially when you are trying to provide content ed
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
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
> > 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 o
20 matches
Mail list logo
