Mailing List Archive

Marcus Doemling wrote:
> I think one key improvement would be to turn mod_perl into mod_embperl.
> What
people really want when they are considering mod_perl is not better performing
CGI scripts it is something like Embperl. I don't think these days there are a
lot of people wanting to do pure CGI programming, so mod_perl by itself in not
"useful".
>
> Both mod_perl and Embperl would benefit if they were combined. As other
people on this list I also have done a lot of investigation about other tools
and Embperl to me is the clear winner and I believe most people would agree -
if they ever tried it out.
>
> So how about Embperl joining forces with the mod_perl people. Is this a
crazy idea or would it be possible. Imagine you just installed mod_(emb)perl
and you're all set with Embperl - ready to create dynamic web pages. What a
winner technology that would be - a PHP killer.

Works for me. I certainly never use one without the other, and using PHP is
just begging to have your server hacked...
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

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

Marcus Doemling wrote:
> I think one key improvement would be to turn mod_perl into
> mod_embperl ...
> so mod_perl by itself in not "useful"...

The idea is nice, though I'd rather see it as a deeper integration into
mod_perl.
mod_perl IS useful.
As an Embperl "end user" I use mod_perl for it's speed and it's
preloading of perl modules.

> ... people on this list I also have done a lot of investigation
> about other tools and Embperl to me is the clear winner ...
IMHO, this is quite true, as for other options I've tried : CGI is like
a slower php with less options, MASON is nice and flexible but not
"human readable", CATALYST is top notch with big framework but seems a
bit of a sledgehammer for small apps.
EMBPERL is clear and easy to maintain no matter the size of your apps.

Thanks again Mr Gerald Richter for pulling this up !

> So how about Embperl joining forces with the mod_perl people ...
Though my abyssimal knowledge of C won't be of any help ...
I plain agree and am eager to see it.

Regards.
--
kolikov@free.fr


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

On Tue, 18 Sep 2007, Marcus Doemling wrote:

>
> I think one key improvement would be to turn mod_perl into
> mod_embperl. What people really want when they are considering
> mod_perl is not better performing CGI scripts it is something like
> Embperl. I don't think these days there are a lot of people wanting to
> do pure CGI programming, so mod_perl by itself in not "useful".

Unfortunately, there are a number of toolkits which are built on top of
mod_perl; EmbPerl isn't the only one. Furthermore, EmbPerl is useful
even without Apache, and thus without mod_perl... I fully admit that it
is *more* useful with Apache, but EmbPerl can also be used to manage
template files outside of a web environment.

> Both mod_perl and Embperl would benefit if they were combined. As
> other people on this list I also have done a lot of investigation
> about other tools and Embperl to me is the clear winner and I believe
> most people would agree - if they ever tried it out.

Different tools are best suited to different tasks. I find that EmbPerl
works best for the tasks for which I need a templating system, because I
usually have a very small amount of dynamic in my pages, and EmbPerl
allows me to do that with minimal impact on my otherwise static pages.
Other projects may be different. For example, years ago, I helped a
friend with a mod_perl project that had very little static data; so
little that he had the opposite issue: he was looking for a way to
shield his mass of perl code from clumps of HTML (and, also, to allow
him to dynamically support different flavors of SGML and XML.) I can't
remember what we eventually selected for him, but I do remember it was
quite definitely not EmbPerl.

> So how about Embperl joining forces with the mod_perl people. Is this
> a crazy idea or would it be possible. Imagine you just installed
> mod_(emb)perl and you're all set with Embperl - ready to create
> dynamic web pages. What a winner technology that would be - a PHP
> killer.

I would have no problem with an additional package that bundled the two,
and was maintained by both orgs. I think that would be great. However,
I feel that merging the groups and the products, and not releasing
stand-alone versions of either would alienate a number of current, loyal
users.

For what it's worth, I am in the camp of using EmbPerl in a standalone
fashion. I am only speaking about the mod_perl without EmbPerl camp
because I know it exists, and I believe strongly that it would also be
opposed to a full merge of the two products.

Ed

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

On Tue, Sep 18, 2007 at 02:21:21PM +0000, Ed Grimm wrote:
> I would have no problem with an additional package that bundled the two,
> and was maintained by both orgs. I think that would be great. However,
> I feel that merging the groups and the products, and not releasing
> stand-alone versions of either would alienate a number of current, loyal
> users.
>
> For what it's worth, I am in the camp of using EmbPerl in a standalone
> fashion. I am only speaking about the mod_perl without EmbPerl camp
> because I know it exists, and I believe strongly that it would also be
> opposed to a full merge of the two products.

I agree; this is a very good point. I am reminded of what happened with
AxKit when the developers decided that it was more "efficient" to turn
it into a standalone server (AxKit2) rather than port it to working with
mod_perl2; they made assumptions about what people would want, and threw
away advantages that the earlier version had (such as being able to use
non-AxKit Apache features rather than having to reinvent the wheel).

My other concern about this proposed merge is who the heck is
volunteering to do all the work? The mod_perl people wouldn't be
interested, they've got their own concerns. They'd probably feel as if
mod_perl was being hijacked by outsiders.

I think a better proposal is simply to recruit Embperl developers (from
where? I don't know) to assist in the improvement of Embperl because
Gerald is swamped and needs help. Recruiting people to improve the
documentation is probably a good idea too.

Think big, but start small.

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

Hi,

It will not work to put mod_perl and Embperl together. Both have
different focus and users.

Mod_perl people will never fix themself to one framework (and I think
that is good).

The only thing that might help (as already suggested) to have an easy to
install installation system that bundles both (like Randy Korbes
maintains for Windows).

From my point of view much more important for Revitalizing Embperl is on
the one hand people that helps developing and testing and on the other
hand do some promontion outside of this list, like writing articles, put
modules on CPAN that uses Embperl and integration it into other
frameworks.

Gerald


------------------------------------------------------------------------
Besuchen Sie unseren Messestand auf der SYSTEMS vom 23. - 26.10. in
München, Halle B3, Stand 425 www.ecos.de/messen-events/systems-2007.html
------------------------------------------------------------------------
Gerald Richter ECOS electronic communication services GmbH
******************* SECURING YOUR NETWORK ********************

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 939-122
WWW: http://www.ecos.de Fax: +49 6133 939-333

Sitz der Gesellschaft: Dienheim; AG Mainz HRB 6889; GF: W.Heck,G.Richter
------------------------------------------------------------------------



> -----Original Message-----
> From: Marcus Doemling [mailto:md7852@hotmail.com]
> Sent: Tuesday, September 18, 2007 7:03 AM
> To: embperl@perl.apache.org
> Subject: Revitalizing Embperl
>
>
> I think one key improvement would be to turn mod_perl into
> mod_embperl. What people really want when they are
> considering mod_perl is not better performing CGI scripts it
> is something like Embperl. I don't think these days there are
> a lot of people wanting to do pure CGI programming, so
> mod_perl by itself in not "useful".
>
> Both mod_perl and Embperl would benefit if they were
> combined. As other people on this list I also have done a lot
> of investigation about other tools and Embperl to me is the
> clear winner and I believe most people would agree - if they
> ever tried it out.
>
> So how about Embperl joining forces with the mod_perl people.
> Is this a crazy idea or would it be possible. Imagine you
> just installed mod_(emb)perl and you're all set with Embperl
> - ready to create dynamic web pages. What a winner technology
> that would be - a PHP killer.
>
> Best,
> Marcus
>
> _________________________________________________________________
> Capture your memories in an online journal!
> http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
> ** Virus checked by BB-5000 Mailfilter **
> !DSPAM:416,46ef5d9e238181408911207!
>
>

** Virus checked by BB-5000 Mailfilter **

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