pas-dev — Development mailing list.

[Pas-dev] Apache, mod_perl and Preloading?

[Kyle R . B. <mo...@vo...>]

For Apache/mod_perl tuning purposes, it's a good idea to add all of your 
modules to the startup.pl that gets loaded when Apache starts.  The usual 
benefits of this are speed (the first request into the server is just as 
fast as the second) and memory utilizaiton (anything loaded by Apache
before the children fork is effectivly shared between the parent and the
child processes resulting in a savings on the order of the number of
Apache processes you have configured).

For page objects and other modules that you write by hand, this is an
easy and straight forward thing to do, you just add the modules to
the end of the startup.pl and off you go.

There are also modules generated from the psp files for your web-site.
Usualy these are generated on the fly in response to HTTP requests to
pages that are either not already compiled, or those that need 
recompliation.

If the compiled psp modules were pre-built (or built by the startup.pl), 
they could be loaded at startup time as well.  Unless I'm interpreting 
things incorrectly, that means that the entierity of your site's dynamic 
content and logic modules could be loaded at Apache startup.

Again, unless I'm mistaken, that type of situaiton should result in a
few benefits, 1: much better initial performance, 2: _significantly_ 
better memory usage by the web/application server.  This should still
fit in even if dynamic re-compliation were disabled (which should be 
the case for production environments).



Does this sound right?  Should we (I) look at implementing something
that can be invoked from startup.pl to do the pre-compliaiton and
pre-loading?  It'd slow down the web-server startup, but if you're
codebase is largely built already it shouldn't be that much of a
hit.  The implicaitons (performance and memory usage) for the final
run-time seem like they'd be more than worth-while.


Feedback?


Kyle

    


-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

[Pas-dev] more on content creation...

[Kyle R . B. <mo...@vo...>]

This goes along with the macro-like caching/pre-compliation system and
the PSP syntax/compiler ideas.

I find myself writing too much code (logic) into my psp files that
does not end up being re-used.  Re-use can fit in at multiple levels,
the first and most ovbious level is across multiple psp files.  That
type of re-use can be achieved through the use of compile-time includes.
Compile-time inclusion isn't always the most appropriate solution though.
It would be nice to be able to write/construct mini-content generators
within the psp page itself.  

I may have said this before, but I've started to look at psp files as
an alternative, though more convienient, syntax for writing perl objects, 
where the main purpose of the object is to produce some type of textual
output.  So I've started to use the psp syntax and compiler as a tool
to make writing these kinds of objects faster for me.  I've
been taking advantage of some of the compiler features by using
the <%[ ... %> tags to inject raw perl code directly into the generated
object.  I've been using it to do things like:

<%[
my @paramMap = qw(foo bar qux);
__PACKAGE__->makeGetSetMethods( @paramMap );

sub request_init
{
  my($self) = @_;
  $self->SUPER::request_init;
  foreach my $p ( @paramMap ) {
    $self->$p( $self->query->param($p) );
  }
  return 1;
}

sub getFormattedData
{
  my($self) = @_;
  return "At: " . scalar(localtime) 
       . " You submitted the following: ("
       . join(', ', $self->foo, $self->bar, $self->qux)
       .")";
}

%>


In the psps where I'm doing things like generating HTML tables, the
pages sometimes repeat some of the same steps for a given cell or
a given row:


<TABLE>
  <% foreach my $obj ( @objects ) { %>
    <TR>
      <% foreach my $attr ( @attrs ) { %>
        <TD><%= uc $attr %> </TD><TD> <%= $obj->$attr || '&nbsp;' %></TD>
      <% } %>
    </TR>
  <% } %>
</TABLE>

Then, perhaps in another table, or elsewhere in the same table, the
same pattern exists in the code.  What I'd like to be able to do is
define a method out of psp syntax.  The best way I can imagine to
communicate this concept is to just show you what I'm imagining:

<%[
sub doRow
{
  my($self,$obj,@attrs) = @_;
%><TR>
<%
  foreach my $attr (@attrs) {
%><TD><%= $attr %></TD><TD><%= $obj->$attr %></TD>
<% }
%></TR><%
  return 1;
}

sub doTable
{
  my($self,@objs) = @_;
%><TABLE>
<%
  foreach my $obj (@objs) {
    $self->doRow($obj,@attrs);
  }
%></TABLE><%
  return 1;
}
%>

I'm not settled on that syntax, but it should illustrate the point.  Then
that code coudl just be invoked:

<BODY>
Data set 1 is:
<BR>
<% $self->doTable(@objs1) %>
<BR>
Data set 2 is:
<BR>
<% $self->doTable(@objs2) %>
</BODY>

Maybe what this is really leading to are the equivalent of taglibs...so
you'd still code the methods (maybe in some other syntax) and then
use it like:

<BODY>
Your data is:
<BR>
<myApp:objectTable objects="@objs" />
</BODY>

and that xml style syntax would explode out into the necesary psp code
to write the table.

The current implementation of the compiler can't support this because
it is line and regex based.  I suspect that if we re-implemented the
compiler with something like Parse::RecDescent we could support this
syntax more easily, and other syntaxes as well (like the taglib style
syntaxes).


Does this mesh with your experiences trying to develop psp pages and 
re-useable content generation?  Was the idea communicated clearly enough?  
Does it have merit? Should we expend resources pursuing it?

Kyle

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

[Pas-dev] On MVC and Re-Use...

[Kyle R . B. <mo...@vo...>]

I had the opportunity of attending an overview of Jakarta Struts [1]
yesterday.  I highly recommend looking at Struts if you haven't yet
done so.  There are quite alot of featues, and pre-build components, in
Struts that are targeted at eliminating the drudgery of building the
web/html part of web applicaitons.

Struts is based around the MVC [Model-View-Container] pattern (see the
book Design Patterns from Addison-Wesley, or [2]).  A co-worker took
us through a tour of an applicaiton he's building using Struts.  Looking
at the JSP files he's building, there are exactly zero scriptlets in
the JSPs (scriptlets: <% %> tags), in fact there are even hardly any
expressions (expression: <%= %> tags).  That means there is, from a
code perspective, no logic in the presentaiton layer at all.  None. 
All the dynamic HTML generation is performed through taglibs.  Struts
comes with quite an extensive library of pre-built and useful taglibs
for you to use.  It also makes it easy for you to develop your own.

Like the rest of J2EE that I've seen, Struts and the MVC pattern 
define a tight set of 'best practices' or 'recommended approaches' to
developing the application and minimizing the amount of code you
dedicate to the presentation layer - leaving you to (largely) focus
on the application logic and design.  It's very clean looking and 
encourages better software design and development.

Struts seems big on re-use of other modules.  It makes extensive
use of other Jakarta [3] projects including Commons [4], Jelly [5]
and Jakarta Taglibs [6].

Struts also abstracts away the process of working with HTTP request
data (GET/POST x-form-url-encoded varaibles).  It uses a container
object (called a Form, which is not directly related to HTML forms)
and validation rules.  Simple validaiton rules are defined in 
an XML configuration file.  They can include data type validation,
length/size and domain of values.  Validation rules defined in that
way are handled by the _archictecture_, so when you write your Action
(an Action object is the entity reposnible for performing applicaiton 
logic in response to some user interaction) the simple validaiton has 
been performed before execution even reaches your code.  At that point
all the relevant request data (that you registered as wanting to 
receive in the xml files) is ready for you in the Form object.  

In the case of failed validation, the default handling returns the user
back to the same HTML page, presented with error messages that you
defined in the validation xml file - and the system not only supports
internationalization, but encourages developers to use it throughly and
completely.  

The taglibs are used to create constructs in the JSP files that transform
into HTML.  They also look at the validation xml and inject javascript
event handlers that perform client-side validation (data type and 
length validation) so that validation is done in the browser (if the
browser supports it) and the user get's a better, more interactive 
experience.  Validation is still performed on the back end though, so
the javascript validaiton script only serves to enhance the user 
experience and is not relied upon for actual validation.

Struts gets you alot of bang for your buck if you stick to their
methodology and approach when developing on top of it.  Similar to
design patterns, refactoring and XP, there is no single aspect of
Struts that can be pointed to as the be-all-end-all killer feature,
but instead it is the approach/toolset taken as a whole that makes
you step back and say 'wow' after you've seen what it has to offer.


If we're giong to continute to evolve Pas, we would be well served by
analyzing Struts, assimilating the good parts, compensating for
the not so good parts that can be made better and leaving the
undesierable peices.



Kyle


1: http://jakarta.apache.org/struts/index.html
2: http://csis.pace.edu/~bergin/mvc/mvcgui.html
3: http://jakarta.apache.org/
4: http://jakarta.apache.org/commons/index.html
5: http://jakarta.apache.org/commons/jelly/
6: http://jakarta.apache.org/taglibs/index.html

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

[Pas-dev] pas/bin CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/bin
In directory sc8-pr-cvs1:/tmp/cvs-serv27435/bin

Modified Files:
	viewSession 
Log Message:
better formatting

[Pas-dev] pas/bin CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/bin
In directory sc8-pr-cvs1:/tmp/cvs-serv26552/bin

Modified Files:
	viewSession 
Log Message:
better formatting

[Pas-dev] pas CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas
In directory sc8-pr-cvs1:/tmp/cvs-serv18590

Modified Files:
	ChangeLog 
Log Message:
added new parameter pas.session.useCompression

[Pas-dev] pas/src/Org/Bgw/Pas CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/src/Org/Bgw/Pas
In directory sc8-pr-cvs1:/tmp/cvs-serv18590/src/Org/Bgw/Pas

Modified Files:
	Session.pm 
Log Message:
added new parameter pas.session.useCompression

[Pas-dev] pas-3.0.20

[Kyle R . B. <mo...@vo...>]

I just created a new release for Pas on SourceForge.  The change log entry
is:

v3.0.20 Thu Apr 10 10:24:05 EDT 2003
  * krb: implemented PSP comments, which are stripped from the psp file
    when the file is read.  PSP comments do not make it into the content
    generated by the generated page object.
  * krb/wjb: added new psp page directive 'raw include'.  The include
    directive adds a set of enclosing braces to introduce new scope for
    included pages, this gets in the way of code blocks (like conditionals)
    that attempt to span include files.  The 'raw include' directive 
    does not introduce the new scoping and subsequently allows for code
    blocks that span include files.
  * krb: changed Session.pm to use Storable instead of Data::Dumper.  This
    will result in smaller serialized sessions and better performance
    as compared to Data::Dumper.  Also did some minor refactoring to the
    session object.  Added viewSession utility program under /bin.


Kyle

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

[Pas-dev] pas/src/Org/Bgw/Pas/Psp CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/src/Org/Bgw/Pas/Psp
In directory sc8-pr-cvs1:/tmp/cvs-serv23307/src/Org/Bgw/Pas/Psp

Modified Files:
	Compiler.pm 
Log Message:
minor finalizations for 3.0.20

[Pas-dev] pas/src/Org/Bgw CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/src/Org/Bgw
In directory sc8-pr-cvs1:/tmp/cvs-serv23307/src/Org/Bgw

Modified Files:
	Config.pm 
Log Message:
minor finalizations for 3.0.20

[Pas-dev] pas/src/Org/Bgw/Pas CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/src/Org/Bgw/Pas
In directory sc8-pr-cvs1:/tmp/cvs-serv23307/src/Org/Bgw/Pas

Modified Files:
	Session.pm SessionPage.pm 
Log Message:
minor finalizations for 3.0.20

[Pas-dev] pas/src/Org/Bgw/HTTP CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/src/Org/Bgw/HTTP
In directory sc8-pr-cvs1:/tmp/cvs-serv23307/src/Org/Bgw/HTTP

Modified Files:
	Header.pm 
Log Message:
minor finalizations for 3.0.20

[Pas-dev] pas CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas
In directory sc8-pr-cvs1:/tmp/cvs-serv23307

Modified Files:
	ChangeLog 
Log Message:
minor finalizations for 3.0.20

[Pas-dev] pas/bin CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/bin
In directory sc8-pr-cvs1:/tmp/cvs-serv23307/bin

Added Files:
	viewSession 
Log Message:
minor finalizations for 3.0.20

Re: [Pas-dev] Run Mulitple Apps in the same Apache instance...

[Mental P. <me...@ne...>]

On Thu, 2003-04-03 at 10:00, Kyle R . Burton wrote:
> - Org::Bgw::Config uses a singelton pattern.  The singelton is at the=20
>   package level.  This means that you can't have multiple configurations
>   loaded.  A requirement for multiple applicaitons.  An approach
>   for solving this (and not incuring the performance hit of loading
>   the configuration on every request) is not clear to me at this time.
> - Org::Bgw::Environment pulls the location of the configuration from
>   an environment variable.  This was originally done because it was
>   portable beteween the mod_perl and standard CGI worlds.  If we gave
>   in and just decided to support mod_perl, we could use a PerlVar=20
>   directive instead of SerEnv/PerlSetEnv.  PerlVar has the advantage
>   that it can be localized to either an Apache Location configuration
>   directive, or a Directory directive.  This would allow mutliple
>   configurations, localized to an alias (in the case of a Location=20
>   directive), to be supported.

I think we should stop trying to support CGI. Any sizable app that tries
to run in CGI mode is going to be very slow and non-scalable. This would
also open the door to us setting varabiles with perlsetvar as you
pointed out.

What if we subclassed the requesthandler on a per-application basis?
Register a uri /cust1 /cust2. Each one has a slightly different request
handler that is specific to their app. Can the request handler take a
parameter and deal with getting config pointed to the right place? Then
again, perlsetvar in a location block would do too.=20

=20
> - Any singelton pattern must be reworked to include a parameter to
>   identify the singelton to be retreived.  In the case of the configurait=
on
>   it might just be the full path and file name of the configuration file.
>   Or we could introduce a new PerlVar that acts as this kind of switch.
>   Perhaps we could just use the virtual-host's name?  That might be a goo=
d
>   approach for solving alot of these issues.

We could also look at using the uri. dev.domain.com/cookbook would be
different from dev.domain.com/icecastcontrol that way.=20

> - Developers would have to know the implications of using globals, static
>   variables - singeltons by any other name.
>=20

They sort of have to now, but yes. That would be an issue. Then again,
developers would be sharing pas/src, and still have their own pageobject
directory where singleton/static whatever wouldnt matter. This sort of
cames back to an idea I was kicking around about making the default page
psp's derive from easily configured/subclassed....=20



>=20
> Beyond that, can we solve the ISP's delima?  So that mod_perl/Pas could
> be used in a web-hosting type of environment where tens or hundreds of
> seperate web-sites all run in the same suped-up Apache process?  Is
> Apache2/mod_perl2 working on this problem?  To summarize, the problem
> here is that the mod_perl namespace is shared - so if I set a variable
> in my codebase $Foo::Bar, anyone else running in the same Apache instance
> can access it (and worse, change it).

Cant really speak to this. The solution is of course... colocation.
Beyond that, I cant think of a serious answer to this. I havent read
much on modperl for apache2 yet.=20


--=20
Mental (Me...@Ne...)

"Shouting at people who, for one reason or another, cannot hear you=20
is mentally-ill behavior -- or evidence of idiots in command."

--George Smith, a virus researcher and columnist for SecurityFocus.=20

CARPE NOCTEM, QUAM MINIMUM CREDULA POSTERO.

GPG public key: http://www.neverlight.com/pas/Mental.asc

[Pas-dev] pas/htdocs/examples/hip CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/htdocs/examples/hip
In directory sc8-pr-cvs1:/tmp/cvs-serv22657

Modified Files:
	image.psp 
Added Files:
	_hipWordFunctions.psp 
Log Message:
update to hip code..more modular, refactored

[Pas-dev] Run Mulitple Apps in the same Apache instance...

[Kyle R . B. <mo...@vo...>]

We're about to roll out another application built off of Pas where
I work.  Since the existing web-server isn't even close to running at
capacity, we'd like to install the new app on the same box.

The new applicaiton introduces a few new derived page objects and psp
pages to go with them.  Both applicaitons run from the same codebase.  
The remainder of the differences are just some configuration chagnes to 
the pas.conf file.

The only way I can see to do this right now is to set up a second instance
of apache driven off of slightly different configuation files that point
to the new codebase and configuration file.  Then this second instance
becomes the new app and the first instance continues to be the first app.
The problems with this are probably obvious - it's more work-load for the
box in question (double the number of apache instances) and it increaces
maintenence issues.  Plus, we'll probably have to set up three Apache
instances, where the first proxies to the other two based on the virtual
host settings.  This may be an unnecessarily complex setup.



What I'm interested in discussing at this point are the issues surrounding
attempting a multiple installation like this.  I think that given the 
current implemenation of some of the modules, and the convention of
using singeltons (either package my's, package our's, or variables
that are lexically captured closure style at compile-time) for some
code constructs (like the singelton configuration object) prevents
multiple applications from being hosted in the same process space.

Are there changes we can make to Pas to allow for this type of configuration?
Are they worh doing?  I'm not sure I know of any other application servers
that allow for multiple instances of the same codebase (multiple applications)
to be hosted in a single process space.

The issues I can identify are the following:

- Org::Bgw::Config uses a singelton pattern.  The singelton is at the 
  package level.  This means that you can't have multiple configurations
  loaded.  A requirement for multiple applicaitons.  An approach
  for solving this (and not incuring the performance hit of loading
  the configuration on every request) is not clear to me at this time.
- Org::Bgw::Environment pulls the location of the configuration from
  an environment variable.  This was originally done because it was
  portable beteween the mod_perl and standard CGI worlds.  If we gave
  in and just decided to support mod_perl, we could use a PerlVar 
  directive instead of SerEnv/PerlSetEnv.  PerlVar has the advantage
  that it can be localized to either an Apache Location configuration
  directive, or a Directory directive.  This would allow mutliple
  configurations, localized to an alias (in the case of a Location 
  directive), to be supported.
- Any singelton pattern must be reworked to include a parameter to
  identify the singelton to be retreived.  In the case of the configuraiton
  it might just be the full path and file name of the configuration file.
  Or we could introduce a new PerlVar that acts as this kind of switch.
  Perhaps we could just use the virtual-host's name?  That might be a good
  approach for solving alot of these issues.
- Developers would have to know the implications of using globals, static
  variables - singeltons by any other name.



Are there any other issues that anyone can think of?  Can we solve these
and host multiple apps in the same process space?

Beyond that, can we solve the ISP's delima?  So that mod_perl/Pas could
be used in a web-hosting type of environment where tens or hundreds of
seperate web-sites all run in the same suped-up Apache process?  Is
Apache2/mod_perl2 working on this problem?  To summarize, the problem
here is that the mod_perl namespace is shared - so if I set a variable
in my codebase $Foo::Bar, anyone else running in the same Apache instance
can access it (and worse, change it).


Kyle

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

[Pas-dev] pas/src/Org/Bgw/Pas/Psp CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/src/Org/Bgw/Pas/Psp
In directory sc8-pr-cvs1:/tmp/cvs-serv19975/src/Org/Bgw/Pas/Psp

Modified Files:
	Compiler.pm 
Log Message:
added new compile-time directive to fix brace issues when code blocks span multiple include files

[Pas-dev] pas/src/Org/Bgw/Pas CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/src/Org/Bgw/Pas
In directory sc8-pr-cvs1:/tmp/cvs-serv19975/src/Org/Bgw/Pas

Modified Files:
	Page.pm 
Log Message:
added new compile-time directive to fix brace issues when code blocks span multiple include files

[Pas-dev] Get/Set Member Functions for PSP Pages?

[Kyle R . B. <mo...@vo...>]

Right now I find myself wanting get/set member functions in my PSP pages.
To accomplish this, I'm using a trick:

<%-- a bunch of HTML and PSP code --%>

<%[
__PACKAGE__->makeGetSetMethods(qw( meth1 meth2 ));

sub someOtherMethod
{
  return 'foo' + 3;
}

%>

Should we add a real facility to the PSP Syntax/Compiler for this?
Maybe something like:

<%@ page memberVariables = " meth1 meth2" %>


What do you think?  I don't like the __PACKAGE__ 'trick', it
doesn't feel like good programming practice.  It does work, but
it feels like I'm circumventing the spirit of the PSP system.
Of course by adding all this stuff I may be putting logic in
my presentation layer that shouldn't be there...but maybe
not - PSP was designed to allow you to code in just PSP and not have
to create and register page objects...that raises another idea: being
able to declare some other PSP file as your parent, by only 
referencing the file, and not the fully generated package name that
the file will translate to.



Kyle



-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

[Pas-dev] pas/htdocs/examples/hip CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/htdocs/examples/hip
In directory sc8-pr-cvs1:/tmp/cvs-serv11215/htdocs/examples/hip

Modified Files:
	image.psp 
Log Message:
hip example of random image generation

[Pas-dev] pas/htdocs/examples/hip CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/htdocs/examples/hip
In directory sc8-pr-cvs1:/tmp/cvs-serv9643/htdocs/examples/hip

Added Files:
	image.psp 
Log Message:
random image generator

[Pas-dev] pas/htdocs/examples/hip CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/htdocs/examples/hip
In directory sc8-pr-cvs1:/tmp/cvs-serv9152/hip

Log Message:
Directory /cvsroot/pas/pas/htdocs/examples/hip added to the repository

[Pas-dev] pas/src/Org/Bgw/Pas/Psp CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas/src/Org/Bgw/Pas/Psp
In directory sc8-pr-cvs1:/tmp/cvs-serv5120/src/Org/Bgw/Pas/Psp

Modified Files:
	Compiler.pm 
Log Message:
implemented PSP comments

[Pas-dev] pas CVS commit

[Kyle R. B. <mo...@us...>]

Update of /cvsroot/pas/pas
In directory sc8-pr-cvs1:/tmp/cvs-serv5120

Modified Files:
	ChangeLog 
Log Message:
implemented PSP comments