On Thu, 2003-06-05 at 06:00, Autrijus Tang wrote:
> On Sun, Jun 01, 2003 at 10:47:59AM -0500, Nathan Byrd wrote:
> > Additionally, I could see a benefit for non-web based PAR files. For
> > base modules, CPAN modules, etc which are included into a PAR archive,
> > they could be grouped into separate archives within the main archive, so
> > when the PAR is uncompressed the resulting file structure is still
> > readable. Maybe something like a par/ directory (by default) inside a
> > PAR file to allow it to recurse...
>
> Implemented in the snapshot version (http://p4.elixus.org/snap/PAR.tar.gz).
> Let me know if this is what you want -- basically it checks for all Zip
> files under par/, and recursively adds them to known PAR sources.
>
Cool - I'll take a look at the snapshot, thanks!
> > Is it possible for PAR to set an environment variable (like PAR => 1, or
> > better yet, PAR => "/path/to/par/file.par") when executing code from a
> > library which is inside a PAR archive?
>
> You can already check for $INC{'Module/Name.pm'} and see if it comes
> from a CODE reference. This is a pretty good indication that your
> code is being run from somewhere abnormal. :-)
>
> > Alternatively, as a possibly better approach could we force a symbol
> > entry for each package so a module author could check for that? For
> > instance, if the DBI package was found and loaded from a PAR archive, it
> > would create a scalar in the DBI symbol table something like $DBI::PAR =
> > "/path/to/par/file.par";.
>
> I am wary of exporting stuff into any symbol tables; besides, we have
> no idea what additional packages a module may declare, as Nicholas has
> pointed out. So for the time being I think checking
> $INC{'Module/Name.pm'} (and comparing it against \&PAR::find_par if you
> must) is the safest bet.
>
For the same reasons as I had in my previous email to Nicholas, this may
be a little obscure. Really I'm looking to be able to tell module
writers that with a couple of lines of code they can read files
regardless of whether their module, registry script, perlrun script, etc
is currently running inside an archive, and was hoping to avoid anything
more than "call this function which either opens a file on the local
filesystem or inside the current archive and returns a file handle".
Probably I'm going a bit far anyway though...
I did have another possible approach to this. I'm thinking about adding
a "tag" to the web.conf spec which would allow a content developer to
expand some of the archive onto the filesystem during Apache startup.
This could reduce the need for a solution like the above.
Thanks,
--
Nathan Byrd <[EMAIL PROTECTED]>
