perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Gunton <n...@nilspace.com>
Subject Some observations
Date Wed, 23 Jul 2008 22:34:39 GMT
Ok, so I just completed a major upgrade of my websites from Apache 1.3, 
mod_perl 1, Embperl 1.3 to Apache 2.2, mod_perl 2 and Embperl 2.3.0. It 
was not a simple or painless experience, to say the least. Why on earth 
didn't the Apache/mod_perl people provide a compatibility layer for 
their API. It's simple enough using the new version if you're building a 
site from scratch, but not if you're upgrading a large existing 
configuration. But that's not my main point. I have some observations 
and a couple of questions:

1. What is up with Embperl? I have written to Gerald Richter both via 
this list and directly to his email address, and had no answer. I also 
wrote to Angus Lees about the Debian Lenny Embperl package being broken 
but got no reply. The email archives here are full of spam. It really 
gives an "abandoned house" impression which is sure to turn off any 
prospective new users. If I was a potential user, and I came onto the 
Embperl site to check out the community, I would assume that this is a 
dying or dead project. Is Embperl still being actively developed, or has 
Gerald effectively put this to sleep? Has the likes of Ruby on Rails and 
PHP put Embperl firmly into the history books, or is this actually still 
an active project? If Gerald isn't all that "into" developing it any 
more, is there any potential for someone else to take it on in a more 
active way?

2. When I upgraded my sites to Embperl 2, I noticed that some things 
broke, in particular forms handling. I tracked down the problems to 
Embperl not apparently failing to include fdat values in the [$hidden$] 
block, when the fdat value was not passed into the request or included 
in the form explicitly as a hidden input tag, but was rather created in 
the code. This worked in Embperl 1.x; I could create for example 
$fdat{xxx} and then xxx would be included as a hidden variable in the 
[$hidden$] block. I fixed the problem by explicitly inserting a "hidden" 
input tag for the relevant variables, and these are now set from fdat by 
Embperl. I don't know whether this new behavior is somehow "correct" and 
the old behavior was just accidentally working. I do think that it would 
be desirable for anything inserted into fdat to be included in a 
[$hidden$] block, even if it didn't come into the request in fdat.

3. Embperl 2 was supposed to be much more flexible with respect to 
Syntaxes. However I haven't found this to be the case. For example, I 
have a lot of existing code which now breaks because of the TABLE and TR 
handling which doesn't seem to handle these elements being parts of 
conditional blocks. It seems to look at the straight number of such 
tags, without consideration as to whether they are conditionally being 
applied or not in [$if$] blocks. I wanted to turn off handling of just 
the table tags, but couldn't find a way to do that easily using the 
Syntax functionality. I would have to use EmbperlBlocks by itself, 
leaving out EmbperlHTML. But as far as I can tell, EmbperlHTML is 
necessary to enable forms handling, which I do very much use. In any 
case, I couldn't even get the 'syntax' parameter to Embperl::Execute to 
work when preloading my pages. It didn't seem to make any difference if 
I put 'syntax => "EmbperlBlocks"', the table errors still came up during 
the preload phase, as if it was still just using the Embperl syntax 
(i.e. EmbperlBlocks + EmbperlHTML). The only way I could work around 
this to get it to work was to abandon the concept of setting the syntax, 
and just manually hack the EmbperlHTML.pm module in the Embperl codebase 
to remove all the bits that seemed to deal with table processing, then 
recompile Embperl. Given the supposed flexibility of the Syntax 
functionality, I think this is a very clumsy way to do it. Every time I 
compile a new version of Embperl, I will have to remember to go and 
manually edit that file before compiling. Surely it would be better if 
there was a (working) method of specifying exactly what aspects of the 
HTML processing you would like to keep, and what you would like to 
switch off.

4. The test phase of Embperl seems to be broken in 2.3. It comes back 
with this:

...
#7 plainblock.htm...          ok
#8 plainblock.htm...          ok
#12 error.htm...

[-1]Missing right curly or square bracket at 
/usr/src/Embperl-2.3.0/test/html/error.htm line 60, at end of line

In closing, I'd like to comment that I'm very grateful to Gerald for 
writing Embperl. However I honestly think it was a case of "over 
abstraction" to completely rewrite everything for version 2, which then 
took so long to get to being stable. I am a major user of Embperl, but 
put off upgrading to version 2 of the whole Apache/mod_perl/Embperl 
stack because it was just so buggy for so long. I know that Gerald 
wanted to design a better version which would then be so much more 
flexible and powerful, but all I really wanted was a simple, working 
Embperl that lets me embed Perl in HTML. The original version of Embperl 
did just that, and very well too. So we were stuck for a long time with 
this "second system" effect, where we can either use the old, stable 
version which isn't being maintained any more, or the new, buggy, 
incompatible version which is the new "official" version. Who uses 
'recipes' or 'syntaxes' anyway? I just want to embed Perl in HTML. Isn't 
this a case of too much abstraction? Especially when the new version 
breaks existing code. I wonder if all that time where mod_perl has been 
stuck in limbo because version 2 wasn't ready for prime time yet was one 
of the things that made people leave it behind for things like PHP and 
Ruby on Rails. I find that I committed myself to a technology eight 
years ago (Embperl) which I felt (and still feel) is a wonderful 
concept, but the world in the meantime seems to have moved on and this 
is now something of a backwater. Nobody is looking for Embperl skills. I 
think that's kind of sad, given the potential we had here. There used to 
be a vibrant community of new users asking how to do this or that, but 
now all we have is a bunch of Japanese porn in the email archives, and 
no answers from Gerald. I find this very sad, to be honest.

Thanks,

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Mime
View raw message