Re: [Text-forge-devel] Text::Forge and PAR

[Maurice A. <ma...@re...>]

Aaron Patterson wrote:
> On Tue, Aug 12, 2003 at 09:35:38PM -0700, Maurice Aubrey wrote:
>>The thing is, there's no reason why Apache::PAR can't unzip the archive
>>behind-the-scenes to a temp directory. And if we introduce a new
>>substitution for the web.conf file (like ##TEMPDIR##), then we can
>>reconfigure the app to use that temp directory.
> 
> I guess the only thing I really don't like about unzipping an archive, is when
> will you clean up the archive?  I guess it would be the next time you start up
> apache, correct?  Also, would it be possible to start two different instances
> of apache that are configured with the same tempdir?  If so, what if the archive
> each instance is using is different?  i.e. same file names, different content.
> It seems like coordinating that stuff would be a hassle.

Yes, the clean up is an issue. My initial thought was to always unpack 
on startup and use paths like /tmp/par.$$

PARs shouldn't change that often though, so we were thinking it might 
make more sense to keep them around.

With the next implementation, we used MD5 hashes for the directories.
/tmp/par/8f8b8eb20ddc8ba5cdb04e477f8e2b22

That has some nice characteristics. If a PAR is modified the directory 
is automatically changed. We don't divulge any path info to the PAR, etc.

But Nathan wants to support PAR reloading (support for that
will be in the next PAR.pm release) which wouldn't work, since the path
would change but the Apache configuration can't be updated at that point 
-- you'd need to restart the server.

The current approach is to append the full path to the PAR under the
temp dir. Something like /tmp/par/home/maurice/pars/site.par
On start up, last modification times are checked and the PAR is 
re-unpacked if it's been changed.

So having two instances of Apache with different PARs, even if they have
the same name, should work okay. No attempt is made to clean up at this
point. My argument is that we're unpacking into temp directories. So 
it's your responsibility, if you want to use this approach, to keep your
temp dirs clean through cron or whatever. Might be more of an issue 
under windows, I guess.

>>I think that's a much cleaner approach, since you don't need to modify
>>any modules and in fact all the Apache::PAR::* subclasses become
>>unnecessary. There would be no performance penalty for static content,
>>you wouldn't need the caching layer, etc. Everything would just work.
> 
> It sounds like a good idea to me if it is possible to get around the stuff I
> just mentioned.  Maybe using a PID in the dir name, or something.

Can you think of a nice way to handle clean up? Think that's a show-stopper?

These changes are in CVS if you're interested:
http://sourceforge.net/projects/apache-par

-- 
Maurice Aubrey <ma...@lo...>

GPG Key      http://lovelyfilth.com/~maurice/gpg
Fingerprint  1568 87BB 8934 F186 D116 1BC2 8BD1 F4E9 1C19 E0DF