G'day PAR users and developers,

I'm giving a talk on all the awesome things people have missed in Perl at
the upcoming Linux.conf.au in Tasmania, Australia[1].  Included in this list
is PAR.  While I've been using PAR to build stand-alone executables and .par
files for a while now, I'd like to be able to showcase some of the more
advanced features.

I've got some specific questions with things I've been toying with, but
before I ask them, I want to note that any sort of input on what I should be
showcasing here is appreciated.  If there's something cool that can be done
with PAR, then feel free to mention it, and I'll see if I can get it into my
talk[2].

Recently I've been toying with the idea of remote repositories.  I had a
PAR-using friend comment to me recently that they got in a bit of a knot,
with different users and machines having different versions of their .par
files, which made things more complex than they'd like.

It struck me that remote repositories could solve this sort of problem.  One
could simply distribute minimal code that will automatically fetch the
desired application, supporting modules, and upgrades where appropriate:

        use PAR { repository => 'http://my.example.com/', upgrade => 1 }
        
        # We can now run our application based purely on code loaded
        # from our remote repository...

        My::App->run();

Due to time constraints, I haven't actually tried the code above, and
there's one thing in particular I wanted to check before I did.

Is the 'upgrade' option actually respected when used in the form described
above?  I know that I can use 'install => 1' to install .par files form the
repository, but I'd like them to be upgraded when they change.

>From my examination of the code (PAR::_import_repository) I *can* see the
install option being passed to PAR::Repository::Client (as auto_install),
but there seems to be no passing of the upgrade option[3].

Is there some magic way that the upgrade option is being passed?  Is this
working as intended?, or is this an unimplemented feature?

Finally, when using PAR::Repository::Client (or theoretically the upgrade
option to PAR), is it possible to provide some automatic level of basic
caching?  In order to ensure responsive start-up times, it would make sense
not to contact the remote repository if we already checked it a few minutes
ago, and would make sense to have a short timeout if we can't contact the
repository for any reason.  I understand that one could keep one's own cache
and make appropriate calls to PAR::Repository::Client directly if it's
really desired.

Many thanks in advance for all your help,

        Paul

[1] Talk abstract at
http://linux.conf.au/programme/schedule/view_talk/175?day=friday

[2] This is not a promise that it will be in the talk.  I have both time and
audience constraints.

[3] I can deduce that there *should* be an upgrade option, since
PAR::_import_hash_ref explicitly forbids its use in combination with the
'file' option.

-- 
Paul Fenwick <p...@perltraining.com.au> | http://perltraining.com.au/
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681

Reply via email to