perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Status of Embperl?
Date Fri, 07 Sep 2012 11:28:19 GMT

I think that's the point. Embperl is missing an active  community. Nearly all of the work
is done by myself and (as for most of us) my time is limited. Also Embperl is still alive
and I will keep to maintain it, there could be much more going on if the work would be shared
by more people. To get it back into a living project it would necessary to

-          Update the website

-          Update the documentation (for example Embperl::Form is nearly undocumented
and I guess unused, also it's very powerfull)

-          Creating packages for the main linux distribution 

-          Writing articles (I don't think it's realistic to have a book, but having
articles about it would help a lot)

As already said I am about to create a new release for Perl 5.14&5.16 and I hope to get
some time to do some (minimal) updates on the website (so the project doesn't look dead, as
it seems from the website right now), but that's all I can do for now.

It would be really great, if anybody has a chance to do some of the above work ( other ideas
are always welcome)


From: Ragnar Hákonarson [] 
Sent: Tuesday, September 04, 2012 3:00 AM
To: 'Jose Fonseca';
Subject: RE: Status of Embperl?

I just want to join Jose and air my gratitude to Gerald for his outstanding work and, not
least, his availability which has been acknowledged by many over the years.

I started using Embperl in 1999 and there are projects under my hat that are still at large
today utilising Embperl. I, as many, do not question the robustness nor concept behind Embperl
but have started to question whether Embperl is something to utilise in a new project. Embperl
addresses current needs but the apparent lack of enthusiasts behind it today (apart from Gerald
himself and a few die hard including myself) does beg the question whether it is as a wise
choice for future needs.

I for one would love to see the return of the vibrant community once associated with Embperl
and, as far as I can see, the sudden influx in activity on this mailing list tells me there
may very well still be life in this "animal".

Time to join forces behind Gerald and bring Embperl back to the forefront?

From: Jose Fonseca [] <mailto:[]>

Sent: 03 September 2012 16:08
To: <> 
Subject: Re: Status of Embperl?

> The good news is that I currently working on a payed project which includes fixing Embperl
for Perl 5.14 & 5.16, so hopefully there will be a new release in a few weeks, which solves
all these problems.

That is actually very exciting news. I'd like to thank Gerald Richter for his work and how
available he is for all of us. I've never had a support email go unanswered, so Gerald and
the community around Embperl are definitely at the heart of its success.

About Embperl being alive or not: My job is to maintain a tourism-related system that is now
about 15 years old. 

As most Perl apps, it all started with a simple CGI .pl script which grew and was divided
into modules and became a whole app with time. In 2005 the front end of the system was migrated
to Embperl and we're still using it to this day. In 2006 we migrated 90% of our PHP code into
Embperl and Perl modules. We're still unable to get rid of the PHP module in Apache, because
some of our users publish Wordpress blogs.

We feel that there are pros and cons in our deployment.

Pros: Embperl is extremely stable, well implemented and has been debugged for years. We simply
deploy and forget about it. The Embperl templating system is well thought out, there is no
strange crosstalk between tags, there are no unexpected behaviors and dependency conflicts
in between Embperl sections even though some run at different times(no "magical" and difficult
to debug collateral effects, etc). When I did parallel programming projects which used JSP
or ASP, I immediately felt the diffculty introduced by the excessive complication and bloat
in those technologies. Embperl is very Perl-ish, it makes easy things easy, hard things possible.

When our app grew and a whole host of features were added such as a DBIx::Class ORM backend(which
in turn pulls in hundreds of modules) we had absolutely zero problems with Embperl, it simply
does not mess with the rest of Apache and does not introduce any module incompatibilities
to the rest of our app. Apart from the infamous change in namespace which broke our
upload forms, we've never had an issue with the thousands of modules running in the background
at any given moment. This may seem "obvious" but it's not, it is in fact quite improbable
that with so many dependencies to our app, that it actually runs so smoothly.


Embperl could really use a book. There should be a "Camel book" for Embperl IMHO, nowadays
it could be an eBook, I'm sure the community would buy it. 

The configuration directives currently have two versions, the environment version and the
Apache instruction, that was a source of confusion for our team at some point. I think these
days that could be unified into one standard configuration system. One global config on a
embperl.ini file and a per-application config in a specific location would solve it, getting
rid of %ENV.

Perl JAR
Perl does not have a JAR-like packaging system, so deployments are always tough, we can't
just deploy a package that is then automatically started as an application on the server.
Right now we're using Amazon AMI's for this job, we basically package a whole server as the
application, to avoid 2 hours running CPAN compilations before a server can go up. 

This, of course, is a Perl issue not Embperl, but if you're considering Embperl for a project,
you probably should consider this fact.

Another Con is, Embperl is very low level in order to achieve speed. This couples it to the
OS and to Perl very tightly, thus we get these issues mentioned on this thread now and then,
compilation is straight down to platform-dependent binaries. A Embperl installation in our
development servers does not run on our production servers.

With the price of hardware being ridiculous these days, maybe it'd be a good idea to abstract
more of Embperl into pure Perl instead of C, we may lose some efficiency but then again nowadays
we're more concerned with parallelism and being able to scale sideways. 

Scaling horizontally is very difficult with Embperl. Unless you package a whole server as
the application, every new machine added to a pool will have to run CPAN and update hundreds
of modules, which may take hours. 

So the main con against Embperl is not actually an Embperl issue: Perl urgently needs an application
packaging system like Java already has had for 17 years. Upload a binary and the app is deployed,
that's how simple it should be in 2012. Nobody deserves to sit there and watch GCC compilation
messages scroll by in this time and age, IMHO. You can afford it as a single developer, but
when using Embperl for tens of deployments that is simply undoable.

Aside from that, Embperl has survived this mess of "Web 2.0" booms and busts for us. Our REST
web services are implemented in Embperl, with JSON in the back. The DBIx::Class ORM has held
up to the test of time and our migrations from Apache 1 to 2 to 2.2 and 2.4 have been smooth

So there's our story. Embperl continues to be alive and well for us and we depend on it on
a daily basis with historically near zero downtime due to Embperl itself.


On Mon, Sep 3, 2012 at 4:39 AM, Jean-Christophe Boggio < <>
> wrote:

Le 03/09/2012 09:22, <> a écrit :

The good news is that I currently working on a payed project which
includes fixing Embperl for Perl 5.14 & 5.16, so hopefully there will
be a new release in a few weeks, which solves all these problems.

Great news, be strong !

Jean-Christophe Boggio                       -o) <>                    
Independant Consultant and Developer        _\_V

To unsubscribe, e-mail: <>

For additional commands, e-mail: <>


View raw message