pas-dev — Development mailing list.

[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-serv22192/src/Org/Bgw/Pas

Modified Files:
	RequestInquisitor.pm 
Removed Files:
	RequestTest.pm 
Log Message:
plint, cvs-agent, start of new logging

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

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

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

Modified Files:
	OracleTest.pm 
Log Message:
plint, cvs-agent, start of new logging

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

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

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

Added Files:
	Request.pm 
Log Message:
plint, cvs-agent, start of new logging

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

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

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

Added Files:
	Config.pm Environment.pm 
Log Message:
plint, cvs-agent, start of new logging

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

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

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

Added Files:
	Check.pm CoreChecker.pm 
Log Message:
plint, cvs-agent, start of new logging

[Pas-dev] pas/etc CVS commit

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

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

Added Files:
	log4perl.conf plint.conf test.conf 
Log Message:
plint, cvs-agent, start of new logging

[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-serv22192/src/Org/Bgw

Modified Files:
	App.pm Base.pm Config.pm Environment.pm TestSuite.pm 
Added Files:
	Log.pm Pas.pm 
Removed Files:
	ConfigTest.pm EnvironmentTest.pm 
Log Message:
plint, cvs-agent, start of new logging

[Pas-dev] pas/bin CVS commit

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

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

Modified Files:
	runUnitTests 
Added Files:
	cvs-agent plint 
Log Message:
plint, cvs-agent, start of new logging

[Pas-dev] pas CVS commit

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

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

Modified Files:
	ChangeLog 
Log Message:
plint, cvs-agent, start of new logging

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

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

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

Log Message:
Directory /cvsroot/pas/pas/src/Org/Bgw/Plint added to the repository

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

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

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

Log Message:
Directory /cvsroot/pas/pas/src/Org/Bgw/Pas/Test added to the repository

[Pas-dev] pas/etc CVS commit

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

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

Log Message:
Directory /cvsroot/pas/pas/etc added to the repository

[Pas-dev] pas/conf CVS commit

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

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

Added Files:
	log4perl.conf 
Log Message:
need to integrate logging

[Pas-dev] pas CVS commit

[Justin B. <j0...@us...>]

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

Modified Files:
	ChangeLog 
Log Message:
Modified Response.pm to use IO::Handle instead of an array for it's buffered
output.  It appears to be much more efficient.

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

[Justin B. <j0...@us...>]

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

Modified Files:
	Response.pm 
Log Message:
Modified Response.pm to use IO::Handle instead of an array for it's buffered
output.  It appears to be much more efficient.

[Pas-dev] IO::Handle

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

I've got a co-worker that's implementing an XML to XLS converter.

While discussing the implementation, the idea of using IO::Handle as the 
standard interface came up as an easy way to support a variety of input 
and output targets.  IO::* supports files, sockets, scalars [strings],
etc.

After a minute I thought about Pas and the buffering mechanisim used
by the response object.  Why not replace the guts of the response 
mechanisim with an IO::Handle object?  The net difference to the
codebase would be largely invisible because we'd start with the current
approach of buffering into a string (IO::Scalar or IO::Stirng) and
returning the whole thing at the end of the request life cycle.

The big win would be that if we wanted, we could then switch out the
string with a handle to stdout (the socket) and have an unbuffered
response object.  There is already a <%@ page buffer ... %> tag in 
the syntax of PSP, we just don't support it - this change would allow
us to start to support it.  I'm sure the users of Pas would want that
capability.  Unbuffered output would be less than ideal for exception
handling, but websites might really want it for performance reasons.
Pages would begin rendering sooner in most browsers (especially if
the pages were large), less data would end up buffered in the Apache
process, possibly saving memory, etc.


What do you think?


Kyle


-- 

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

[Pas-dev] Symbol Module

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

I just learned about the existance of Symbol::delete_package, which
can delete all the symbols defined in a package.  That operation is useful
if you're reloading a module and want to have it's namespace cleared
out before it gets reloaded.

  "Symbol::delete_package" wipes out a whole package namespace.  Note
  this routine is not exported by default--you may want to import it
  explicitly.


I don't have time right now to look into it, but this might be a good
approach for when we reload PSPs or if we ever get to the point where
we can register and load uri handlers at run-time (for the de-register
part).


Kyle

-- 

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

Re: [Pas-dev] mod_perl resource

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

> > http://www.take23.org/
> >
> > I just saw that, thought the group would be interested.
> >
> > Kyle
> 
> Erm, the news on the front page and in the new section is
> almost exactly two years old.  It doesn't look like much
> has happened on this site for a while.  It does have some nice
> links and articles even so.

Yes, I'm sorry about that.  I failed tolook at how recent the posts were 
before I mailed this list.


Kyle

-- 

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

Re: [Pas-dev] mod_perl resource

[Kyle H. <kh...@qu...>]

On Friday 13 June 2003 09:49, Kyle R. Burton wrote:
> http://www.take23.org/
>
> I just saw that, thought the group would be interested.
>
> Kyle

Erm, the news on the front page and in the new section is
almost exactly two years old.  It doesn't look like much
has happened on this site for a while.  It does have some nice
links and articles even so.

Best,
Kyle (another one)

[Pas-dev] XML::Simple

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

I've built a few Pas based applicaitons at work and attempting
to manage potentially complex, nested or hirarchical configuration data
is becomeing a bit tiresome using the key=value syntax of the current
configuration object.

We were talking about the configuration use cases for another peice of
Perl software at work and Chip Salzenberg poitned out XML::Simple.  

It's a fairly standard module (Mandrake has an rpm for it).  Take
a quick look at the perldoc, it gives a great overview of how easy
it really is to use.

In the case of Pas, we could be using XML::Simple to read and write
configuration file(s).   We could start to seperate out different
aspects of the system, like Pas configuration from URI/page registration.
We could introduce the concept of data sources (similar to Struts), where
you configure the DBI dsn(s) in the configuration and then just
request the dbi handle by logical data source name.

If the page registraiton is seperated out into a series of one or more
files, it might be easier to re-configure or add in new registered page 
objects at run-time without restarting Apache.

Using an XML formatted configuration file openes up the ability to store
more complexly structured configuration data.  It would make the 
configuration data easier to process by external tools (someone could
create a configuration GUI, and all it would need to know about would
be the XML syntax).

Plus XML is more politically palletable, and switching to XML for
the configuration syntax might push us to integrate it into
other areas of Pas as well.


That's about it for the configuration idea.  I've got another random
idea that you can read below if you're interested.




Hrm...I just realized that the whole DDL XML idea from before could
easily become a reality using XML::Simple.  Create your database meta 
description in XML, run a utiilty to generate the DDL for creating
the database itself:

   xmlddl --ddl --db Oracle dataModel.xml
   xmlddl --ddl --db PostgreSQL dataModel.xml
   xmlddl --ddl --db MySQL dataModel.xml

Then a tool (maybe the one tool generates the objects as well) to
generate the data access layer:

   xmlddl --obj --db PostgreSQL --package MyApp::DB --parent MyApp::DB::Base dataModel.xml

The idea of xmlddl to generate object wrapper(s) could be easily extended
to other languages as well.  Since the ddlxml should be listing foreign
key relationships, the generated code should be able to automatically
work in table joins so with the generated code you might be able to
do something like:

  my $product = $dataSource->load(
    'product',
    'filter' => {'ID' => '01234' },
    'join'   => { table => 'price', 'filter' => {'cust_id'=>123} }
  );

and the dataSource would be smart enough to know that the 'product' table
corresponded to some object, and to load the pricing records by joining
with a fk based on the ddlxml, and a filter for cust_id...

A tool to try to reverse-engineer the db into the ddlxml would be a good 
starting piont for many projects.  Another interesting twist on top of
that idea is:

  http://diffxml.sourceforge.net/

If we had a reliable 'ddlxml --reverseEngineer', you could xmldiff your
database changes to arrive at the necessary alter table commands necessary
to syncronize two database instances between versions or environments.


Kyle

-- 

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

[Pas-dev] mod_perl resource

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

http://www.take23.org/

I just saw that, thought the group would be interested.

Kyle

-- 

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

Re: [Pas-dev] Suggestion for logging

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

> >      if( $log->is_debug() ) {
> >        $log->debug("somethingComplicated, self = ", Dumper($self) );
> >      }
> 
> I like everything except the if $log->is_debug. I haven't looked into or
> spent more than 2 seconds thinking about implementation, but wouldn't it
> be easier if you just wrapped it (log4perl) with Org::Bgw::Log? Then you
> could just call $self->log()->debug like usual. Let the wrapper do the
> debug level check and just return if its not set. IF it is set, it can
> call its getLogger method and log stuff. It'll be better separation
> between page objects and log levels. It'll avoid needless instantiations
> of the lob ogject and simplify the interface.  Know what i mean? 

"if( $log->is_debug() ) {" is an _optimization_.  You don't have to use it.
In the example case I gave, the point was that "Dumper($self)" could be
an _expensive_ operation to perform at run-time -- for Dumper to produce
the string representation of "$self".  If you didn't wrap the call with
the "is_debug" test, then Dumper is invoked, the argument list for the
"debug()" call is built (which might be expensive), "debug()" is called,
and then it decides to throw away all the work that Dumper did because
the log level isn't high enough.  Does this make sense?  

You don't have to use "is_debug" (or is_info, is_error, etc.) if you don't 
want to.  The thing to keep in mind is that the argument list you put
in your code gets computed regardless of the log level.  The conditional
prevents that code from executing.

Log4perl already does the "is_debug" test internally, the example there
was just to point out that inefficiencies existed and one approach for
overcoming them.


As for the "$self->log->debug" approach automatically detecting the caller
and constructing the logger, you could wrap all of it that way.  The
issue with that, I beleive, is again overhead and efficiency.  If having
all these instantiated loggers turns out to be an issue then we can
explore optimizing it.  Based on my experience using Log4j it has yet
to be an issue - the logger instances tend to be very light weight.

> That and depending on the names of the log levels it'd be a transparent
> change. The only differences would be config file stuff and suddenly you
> can log on a per-package basis. 

There are good reasons to follow the convention of using the package name,
but there can also be good reasons not to.  You might want to mix
metaphores in the code - you might actually want to use a specific logging 
context for any of a few reasons -- maybe you want to include a database
reference in the logging context, or a different context for administrative
users logged in to your software.  

The logging infrastructre could also be used for reasons other than code
inspection - you might want it to act as a simple insturmentation api.
The use of a 'profile' log context could allow you to enable/disable
in-code insturmentaiton of portions of the codebase.


Thanks for the discussion.

Kyle




-- 

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

Re: [Pas-dev] Suggestion for logging

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

On Thu, 2003-06-12 at 19:05, Kyle R. Burton wrote:
> In the Java projects I've been involved with, we've used Jakarta's
> Log4j.  Probably the most important features of the logging library are
> that you can tweak the logging level or the destination(s) from a
> configuration file.
>=20

I'm familiar, if not well versed, with how it works. Its a pretty cool
idea.


>   ###
>   package Org::Bgw::Log;
>   ...
>   use Log::Log4perl;
>   Log::Log4perl->init($ENV{'PAS_BASE'}."/conf/log4perl.conf");
>   # get a Log4perl log object based on the caller's package name
>   sub getLogger { Log::Log4perl::get_logger( (caller)[0] ); }
>=20
>=20
> Then in any random module:
>=20
>   ###
>   package Org::Bgw::Foo;
>   ...
>   my $log =3D Org::Bgw::Log::getLogger;
>=20
>   sub somethingComplicated
>   {
>      my($self) =3D @_;
>=20
>      # testing log->is_debug is an optimization so that Dumper isn't
>      # called (since it could be expensive) unless the log level is set
>      # to debug -- unless the level is debug, the arguments aren't
>      # computed, and the log statement isn't called.
>      if( $log->is_debug() ) {
>        $log->debug("somethingComplicated, self =3D ", Dumper($self) );
>      }

I like everything except the if $log->is_debug. I haven't looked into or
spent more than 2 seconds thinking about implementation, but wouldn't it
be easier if you just wrapped it (log4perl) with Org::Bgw::Log? Then you
could just call $self->log()->debug like usual. Let the wrapper do the
debug level check and just return if its not set. IF it is set, it can
call its getLogger method and log stuff. It'll be better separation
between page objects and log levels. It'll avoid needless instantiations
of the lob ogject and simplify the interface.  Know what i mean?=20

That and depending on the names of the log levels it'd be a transparent
change. The only differences would be config file stuff and suddenly you
can log on a per-package basis.=20

Hopefully this is coherent.....=20

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

Distant - An approaching age
When this document falls beneath another's gaze
Too late - We have lost the dawn
The signal's loud and clear, but the transmitter's gone

--Assemblage 23 "Document"

[Pas-dev] Suggestion for logging

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

In the Java projects I've been involved with, we've used Jakarta's
Log4j.  Probably the most important features of the logging library are
that you can tweak the logging level or the destination(s) from a
configuration file.

The logging level (fatal, error, warn, info or debug) can be set across
the entire project, on a per package or a per-object basis.  For
example, if you were trying to watch a constrained set of modules, you
could set up a configuration like:

  log4perl.logger=ERROR, file
  log4perl.logger.Org.Bgw=INFO, screen, file
  log4perl.logger.Org.Bgw.Pas.Page=DEBUG, screen, file
  log4perl.logger.Org.Bgw.Pas.Response=ERROR, file

  log4perl.logger.file=Log::Dispatch::File
  log4perl.logger.file.filename=logs/pas.log
  log4perl.logger.file.layout=Log::Log4perl::Layout::PatternLayout
  log4perl.logger.file.layout.ConversionPattern=%d %p> %F{1}:%L %M - %m%n
  
  log4perl.logger.screen=Log::Dispatch::Screen
  log4perl.logger.screen.stderr=0
  log4perl.logger.screen.layout=Log::Log4perl::Layout::SimpleLayout
  
The first section sets up the default level so only ERROR, or FATAL get
logged.  As a default for all the objects and sub-packages of
Org::Bgw, it sets up a default of INFO or more severe.  For Page
it turns the log level all the way up to DEBUG, while turning it back
down to ERROR for Response.

To make the support easier, since perl can detect the calling package,
we could centralize the configuraiton and obtaining of the logger to a
single module:

  ###
  package Org::Bgw::Log;
  ...
  use Log::Log4perl;
  Log::Log4perl->init($ENV{'PAS_BASE'}."/conf/log4perl.conf");
  # get a Log4perl log object based on the caller's package name
  sub getLogger { Log::Log4perl::get_logger( (caller)[0] ); }


Then in any random module:

  ###
  package Org::Bgw::Foo;
  ...
  my $log = Org::Bgw::Log::getLogger;

  sub somethingComplicated
  {
     my($self) = @_;

     # testing log->is_debug is an optimization so that Dumper isn't
     # called (since it could be expensive) unless the log level is set
     # to debug -- unless the level is debug, the arguments aren't
     # computed, and the log statement isn't called.
     if( $log->is_debug() ) {
       $log->debug("somethingComplicated, self = ", Dumper($self) );
     }

     eval {
       $log->info("Entering log running loop...");
       while(...) {
       }
       $log->info("major processing completed");
     };

     if($@) {
       $log->fatal("Woah, bad error in main processing, aborting: $@");
       $self->throw($@);
     }

     reutrn 1;
  }

This article gives a good overview:

  http://www.perl.com/pub/a/2002/09/11/log4perl.html

This is the main project site:

  http://log4perl.sourceforge.net/

It's also available from CPAN (http://cpan.org/modules/by-module/Log/).

The project comes with a few appenders: Screen, File and DBI.  It can
also make use of Log::Dispatch appenders, which include: Email,
FileRotate (good for keeping log files from filling up all free space),
Tk and Syslog.  One thing that could be done for production would be to
set up fatal errors to go to a File appender, and an Email appender
where the Email appender can be used for easy notification of
catastrophic errors.


The functionality is good, the downside is that this introduces another
dependency.  I had thought that Log::Dispatch::Config had these features,
but it turns out that it doens't really.

What do you guys think about switching?  It should be an easy change.

Kyle

-- 
Health Market Science, Inc.
625 Ridge Pike, Bldg. E, Ste. 400
Conshohocken, PA 19428

Office:  (610) 940-4002 x116
Fax:     (610) 940-4003
Email:   kb...@hm...
Web:     http://www.hmsonline.com/


----- End forwarded message -----

-- 

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

[Pas-dev] cookies & redirects

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

Would it be cool if cookies (say session id's for instance) were set
regardless of a redirect or an internal forward? Right now if you
set_redirect, the cookie(s) aren't set. Whats the feeling on changing
this? It'd be useful say if at the entry point that a browser hits your
site (by design or accident) you redirect outside of /pas/. The
session_id would get set along with the redirect so should they come
back... anything else you may have done is still there. Maybe its a
niche thing, but I think it'd be a nice-to have.=20


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

Distant - An approaching age
When this document falls beneath another's gaze
Too late - We have lost the dawn
The signal's loud and clear, but the transmitter's gone

--Assemblage 23 "Document"