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
I agree, the website looks really bad at the moment. When you go to this
page:
http://perl.apache.org/embperl/pod/doc/Embperl.-page-19-.htm
and click on the link to download Embperl, it just sits there saying
'connecting'. It makes it look like this is a dead project, to be
honest, and who knows how many potential Embperl users the site has
turned off. You would never hear from them, so we have no idea.
-Update the documentation (for example Embperl::Form is nearly
undocumented and I guess unused, also it’s very powerfull)
This would be good too, I am sure you did lots of cool stuff in Embperl
2.0 but it's no use if nobody knows about it.
-Creating packages for the main linux distribution
This would be nice, but I know I probably wouldn't use it, since I tend
to build my own Apache (I do two versions, one front end caching reverse
proxy and one back-end mod_perl), and so I don't want an Embperl which
wants to also pull in and install the default Apache Debian packages.
But it would definitely be nice if it was in Debian again, that is
always a sign of the health and legitimacy of a project (for better or
worse).
-Writing articles (I don’t think it’s realistic to have a book, but
having articles about it would help a lot)
I wrote a 'howto' article early on for Embperl 1.3, but somewhere along
the line it got dropped. I also offered to clean up spelling and grammar
for the English version of the documentation, but that was years and
years ago now. If you would like help with any new documentation, then
just let me know and I would be glad to help.
I could also write an article or two on my own website (probably
neilgunton.com) about how I use Embperl. I am kind of weird, though,
while I think I'm an ok programmer in some respects, in other respects I
really don't know much at all. For example, whenever I start looking
deeper into Perl itself, I realize that I pretty much skate
superficially over some of the more powerful aspects of the language in
my own use. I tend to write simple code, which is good, I guess, but
because of that I'm probably not the best person to write about any
gee-whiz super advanced stuff. That said, maybe I know more than I
realize, I mean I've been developing with Embperl for over 10 years now,
so I must know something. Maybe I've been doing some things wrong all
this time, I don't know, but if you like I can try to write something.
Just be prepared for some forehead slapping moments when you see how I
use it! ;-)
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.
Thanks! Let me know if you need any help with anything. If I can help
from my end, I'd be glad to.
It would be really great, if anybody has a chance to do some of the
above work ( other ideas are always welcome)
I have been getting into Google Maps API v3 recently. I actually bought
a book on the topic which I thought would be useful, but in practice I
found that the code samples on Google's own site are most useful. For
me, just seeing how the code is supposed to be used (or was intended to
be used by the developer) is most useful. So perhaps some code samples
of the things you think each feature could be used for? There are lots
of things in Embperl that I don't use, but I'm sure you put them in
there for a reason. If you like, I could help with doing this too, at
least in English, if you can give me the outlines (we can do that
offline if you're up for it) and I can understand what you're talking
about, then I could do that as another article. It would really be most
natural on your website, but since you're busy I can certainly just post
it on my own site and have you link to it. Whatever works, I'm easy.
Thanks again, Gerald, I'm very grateful for all the work you have put
into Embperl over the years.
Neil
*Sent:* Tuesday, September 04, 2012 3:00 AM
*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?
*Sent:* 03 September 2012 16:08
*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 CGI.pm 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.
*Book*
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.
*Config*
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
sailing.
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.
Cheers!
On Mon, Sep 3, 2012 at 4:39 AM, Jean-Christophe Boggio
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: embperl-***@perl.apache.org
For additional commands, e-mail: embperl-***@perl.apache.org