Some observations

[Neil Gunton]

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@...
For additional commands, e-mail: embperl-help@...

['Kathryn Andersen']

On Wed, Jul 23, 2008 at 05:34:39PM -0500, Neil Gunton wrote:

> 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?

I have certainly gotten the impression that Gerald Richter is
not as interested/involved in Embperl as he used to be.

There was a flutter of discussion when someone proposed integrating
Embperl with Catalyst, but nothing seems to have come of that.

> 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?

The potential is there, with FOSS the potential is always there (even if
someone is forced to do a fork) but what is lacking is the will.
In other words, nothing will happen unless somebody steps forward and
*does* something.  But alas, we all wish that someone *else* would do
something, and thus nothing happens.

And, yes, I am guilty of not doing anything, myself, but I'm finding it
hard enough to keep up with my existing FOSS projects, let alone taking
another one on.

Kathryn Andersen
--
 _--_|\     | Kathryn Andersen <http://www.katspace.com>
/      \    |
\_.--.*/    | GenFicCrit mailing list <http://www.katspace.com/gen_fic_crit/>
      v     |
------------| Melbourne -> Victoria -> Australia -> Southern Hemisphere
Maranatha!  | -> Earth -> Sol -> Milky Way Galaxy -> Universe

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

[Thompson, Jon]

It is true that Embperl has become somewhat of a deserted house (at
least that's the impression I get), but like you I believe it is
superior to other alternatives. As far as the fdat hash not working for
you. I think the trick is to also put the keys of %fdat into the @ffld
array. Something like this should work:

[- $fdat{hello} = 'test' -] [# I had this incorrect last time #]
[- push @ffld, 'hello' -]

Since I'm using CGI.pm (don't ask) and not mod_perl I actually set fdat
up manually myself like this:

[- %fdat = %input -]
[- @ffld = keys %fdat -]

Works well. I do wish the community was more active. I dislike PHP (it's
like Perl...just not as elegant) and don't know Ruby.

-----Original Message-----
From: Neil Gunton [mailto:neil@...]
Sent: Wednesday, July 23, 2008 3:35 PM
To: embperl@...
Subject: Some observations

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@...
For additional commands, e-mail: embperl-help@...


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

[Neil Gunton]

Thompson, Jon wrote:
> Since I'm using CGI.pm (don't ask) and not mod_perl I actually set fdat
> up manually myself like this:
>
> [- %fdat = %input -]
> [- @ffld = keys %fdat -]

Thanks for that! I have never used ffld, since fdat always seemed to do
the trick - I could add things to fdat and they would automatically get
added by any [$ hidden $] blocks. Now, apparently in Embperl 2.x this
isn't the case.

I just tried adding this before all my [$ hidden $] blocks:

[- @ffld = keys %fdat -]

At first test, it does seem to fix at least some of the issues I've been
seeing (I have a *lot* of code, so it's going to take a while to track
down everything that's broken due to the upgrade).

Thanks! This is certainly an easier fix than going around and manually
adding those fields that were not in the fdat originally.

Neil

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

[Ed Grimm]

On Thu, 24 Jul 2008, Kathryn Andersen wrote:

> On Wed, Jul 23, 2008 at 05:34:39PM -0500, Neil Gunton wrote:
>> 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?
>
> I have certainly gotten the impression that Gerald Richter is
> not as interested/involved in Embperl as he used to be.

My impression is that Embperl works for Gerald, so he doesn't need to
mess with it as much.  The outstanding issues he is aware of are all
either Windows issues or documentation problems - and documentation
isn't his forte, his interest, his passion.  As such, his highest
Embperl priority right now is making it threadsafe - and even that isn't
a big interest, as he doesn't use Windows.

> There was a flutter of discussion when someone proposed integrating
> Embperl with Catalyst, but nothing seems to have come of that.

Good thing, too - only a few people use Embperl with Catalyst; it would
be a major upheaval for most of the people using both products to
integrate the two.

I think a much better project would be for an indepentant team to
analyze the two packages to figure out how to make them integrate
better, while not crippling either in isolation.  After the resulting
patches are accepted by both communities, they could then work at
marketting Catalyst to Embperl users and Embperl to Catalyst users, to
increase the overlapping segment.

Eventually, one could get to the point where full integration would make
sense.  But before that happens, you'd need to sell me on Catalyst,
because right now I just don't see why I'd be interested in it.

>> 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?
>
> The potential is there, with FOSS the potential is always there (even if
> someone is forced to do a fork) but what is lacking is the will.
> In other words, nothing will happen unless somebody steps forward and
> *does* something.  But alas, we all wish that someone *else* would do
> something, and thus nothing happens.

That having been said, it generally works better for take-overs to be
friendly.  When one forks a project, some of the users stick with the
original tree, and some will take it as a sign to review the rest of the
market again.  That normally doesn't happen if the reigns are simply
handed over, especially if it's to a well-known lieutenant.

Right now, it seems to me that Embperl development has one
lead person, and a handful of casual patch providers.  We have
historically had a couple of other people provide more significant
additions, but there do not really appear to be any 'lieutenant' types
in this project.

If anyone did want to position themselves such that the community might
recognize a friendly takeover, the two areas that seem to me to need the
most help are making Embperl thread-safe, and improving the
documentation.  Additionally, most projects could use major code
refactoring.  I don't know the Embperl code well enoguh to know how much
it could use, but it's normally a fairly safe bet.

Finally, it's usually possible to convince people you know what you're
doing if you take point on most of the support questions, and you almost
always give correct answers.  However, this route generally requires
more volume than this list typically has.

Ed

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