Joshua Chamas wrote:

> Aaron Johnson wrote:
> >
> > If what you are saying is that current EmbPerl code would be able to run
> > almost unchanged under ASP that would be very interesting, but presently
> > my biggest issues with Apache::ASP are:
> >
> > - Doesn't "help" with any HTML.
> >
>
> I think I know what you mean, and I'm not sure that's its worth
> developing those things, is this a big priority?
>
> Embperl:
> <table>
>   <tr bgcolor="[+ $row % 2?'gray':'white' +]">
>     <td align="center"><font size="+1">[+ $multi[$row][$col] +]</font></td>
>   </tr>
> </table>
>
>  VS.
>
> ASP:
> <table>
>  <% for my $row (0..$#multi) { %>
>    <tr bgcolor="<%= $row % 2 ? 'gray' : 'white' %>">
>    <% for my $col (0..$#array) { %>
>      <td align="center"><font size="+1"><%= $multi[$row][$col] %></font></td>
>    <% } %>
>    </tr>
>  <% } %>
> </table>
>

There are other things, like auto href, form elements etc. that are very helpful.  
Perhaps it is the
lack of examples then on how to emulate some of the functions from other modules.

>
> > - QueryString and Form from the Response are separate, this makes a
> > programming headache if you are used to Embperl or if you are not sure
> > what type of input is coming in for some reason.

>
>
> sub Script_OnStart {
>   $Form = { %{$Request->{Form}}, %{$Request->{QueryString} };
> }
>
> does this need a config?
>

I think to help people coming from CGI or EmbPerl that are used to having all params 
in the same
place that having $Form be automatic is a must have. You can have it be an option in 
the globals if
there is any potential performance hit for doing it I suppose ( could it even be on if 
the passed
information was huge since it is referenced or does it have dereference then build a 
new reference?
).  One less thing to add to "remember/keep track" of.  Remember I am a Lazy Perl 
programmer :^).  I
want things under mod_perl to be as simple as possible for new comers, I think have 
POST and GET in
separate variables is only relevant to people coming from MS ASP platform, which is 
good, but not at
the expense of proficient CGI programmers.

>
> > Shouldn't they just be the same information?
> > Is there a need to keep them separate?
>
> Its the ASP API.  I just ported it.
>
> > - Slow processing time, on the Hello World test it is one of the slower
> > ones.  EmbPerl 2.0 is supposed to be even faster then the present
> > version.
> >
>
> Huh?  From http://www.chamas.com/bench/hello.tar.gz, so you
> can run it yourself ...
>
> hello]# ./bench.pl -version -time=15 ASP Embperl
>
> Test Name                      Test File  Hits/sec   Total Hits Total Time sec/Hits  
> Bytes/Hit
> ------------                   ---------- ---------- ---------- ---------- 
>---------- ----------
> Apache::ASP v2.09 2000         h2000.asp   229.1     3444 hits  15.03 sec  0.004365  
> 28997 byte
> HTML::Embperl v2.0a18 2000     h2000.epl   248.7     3732 hits  15.01 sec  0.004022  
> 28809 byte
> Apache::ASP v2.09              hello.asp   395.1     5933 hits  15.02 sec  0.002531  
> 241 bytes
> HTML::Embperl v2.0a18          hello.epl   461.4     6933 hits  15.03 sec  0.002167  
> 219 bytes
>
> Apache Server Header Tokens
> ---------------------------
> (Unix)
> Apache/1.3.14
> OpenSSL/0.9.6
> PHP/4.0.3pl1
> mod_perl/1.24
> mod_ssl/2.7.1
>
> PERL Version: 5.00503
>
> Operating System: Linux 2.2.14-5.0smp (root@porky) (gcc egcs-2.91.66) #1 2CPU [gate]
>
> Sorry, I can't get it much faster on hello world, Embperl is written
> in C, Apache::ASP in perl.  But check out the h2000 tests, much more
> representative of real world templates, not just startup time.
>

My bad, I hadn't looked at the latest results and I wasn't reading the h2000 results 
correctly.

>
> > - Poor error reporting.  This seems to be possibly a resurfaced bug, but
> > when use strict is turned on ( not the global one, but on a per page
> > level ) when testing a page for compliance it gives no intelligent error
> > message as to where the problem might be.  I see in the docs where this
> > has been addressed (fixed) before.
>
> I haven't seen this in a while, give me a test script & I'll fix it.
>

<%
use strict;
$greeting = "Hello";
print "$greeting";
%>
( used Apache::ASP 2.03 and it worked correctly, 2.07 on a different machine and it 
didn't )

This gets me undefined subroutine as the error message.  If I comment out 'use strict' 
it runs fine.

I am getting different messages on more complex pages, but this was working correctly 
before, but I
am not sure when it broke. ( post 2.03 maybe )

>
> > - No automatic variable clean up.  I think EmbPerl runs each page as its
> > own package to keep things "clean" is that possible under Apache::ASP?
> >
>
> ASP does have a UniquePackages feature that could possibly make use
> of this garbage collection, but then you are not in the same package
> as global.asa where you get to init easy to use globals & such,
> its a trade off.
>
> To do things really cleanly, keep one global hash for per
> process data, and then undef it in Script_OnEnd.  The rest
> should be caught by the UseStrict config.
>
> > - No auto form fillin.  I know this has been discussed, I have even made
> > crude code that allows it.
> >
>
> I would like to develop this too.  Thanks for your feedback.
> So I take it you're not particularly interested in the
> compile time feature additions? :)
>

I am interested in the compile time feature, but will it in fact then run any code?  
With EmbPerl it
has custom meta commands and the automated html handling, will those blocks of code be 
passed to
that module or will they simply be lost?  I for one would rather see ASP use some of 
the more
helpful features of other packages, but have them be built in.

My reasons for even suggesting incorporating these items into the core of Apache::ASP 
vs. "leaving
it to the application developer" are:

- Perl programmers are Lazy why should they have to add a function to something that 
could be done
inside the existing structure with little change on the maintainers end and the 
knowledge that it is
done right for the end user.

- There is already code that is outside of the ASP "standard" (Script_OnStart etc.) so 
adding other
features is truly enhancing the reasons to use Apache::ASP vs. MS ASP.

- New users don't want to have to wade through modules and probably can't and for them 
to understand
references is a bit of a stretch.  So yes some of the added code is ridiculously 
simple if you know
what is does, but that is the beauty of being the magician.

- We just aren't all as good as you Joshua :^)

Aaron Johnson

>
> --Josh
>
> _________________________________________________________________
> Joshua Chamas                           Chamas Enterprises Inc.
> NodeWorks >> free web link monitoring   Huntington Beach, CA  USA
> http://www.nodeworks.com                1-714-625-4051

Reply via email to