Re: [PEPr] Call for votes on PEAR::PEAR_PackageUpdate

Again, I don't say this package is bad. I was more searching reasons to vote. Tried to invent some uses to it. The more dependent on PEAR's api, the more I (should) look into it. -- toggg Justin Patrin wrote: >On 3/21/06, Scott Mattocks <scott@crisscott.com> wrote: > > >>bertrand Gugger wrote: >> >> >>>Then I'm definitively too late. >>> >>>Your example of Benchmark is bad choosed, >>>as Benchmark should in any case never add overload to the tested script. >>>I still have in projects some Benchmark doing a minimum through sockets. >>> >>>Sorry, but imho no production stuff can do such auto update. >>> >>> >>Why? Don't you have any applications that check for updates and let you >>know when a new version is available (Thunderbird)? Maybe my example of >>Benchmark was not the best, but PEAR_PackageUpdate would definitely be a >>nice fit for PEAR_Frontend_XXX. When you run PEAR_Frontend_XXX >>PEAR_PackageUpdate_XXX could be used to make sure that you have the >>latest version. The uses of PEAR_PackageUpdate are not limited to other >>PEAR packages. Just like any PEAR package it can be included in any PHP >>application. If you've ever had to support multiple versions of software >>I think you will appreciate the ability to keep all of your users as up >>to date as possible without heavy user interaction. >> >> >> > >I agree with you Scott. > >toggg: remember, this is a *package*, so this is opt-in, not opt-out. >If you don't want this, don't put it in your packages. In addition, >this meant more as a GUI thing. With GUI programs this is far more >useful as it can allow the user to stay up to date. I love auto-update >features in my packages. > > > >>>Some sketches would be better: >>>* just issue a notice for people really wanting a production script "on >>>the edge" >>> >>> >>This requires the user to manually update the package. Which, if the >>user ever does update, can lead to confusion and errors. An automated >>process is more likely to be run and less likely to cause problems down >>the road. Plus error messages should not be displayed in production code. >> >> >> >>>* make a Net_Monitor_Service sub-class which would detect some upgrade >>> >>> > >Yes, toggg, sounds like a great idea. A Net_Monitor_Service class >which uses PEAR_PackageUpdate to check for updates would be cool. >Again, though, this is the choice of the developer to use. This >package is useful even without this. > > > >>You don't need a monitor. You just need to make two calls to the >>packages channel server. One to check for updates the other to do the >>update if needed. PEAR_PackageUpdate is light and easy yet powerful and >>flexible. >> >> >> > > > >-- >Justin Patrin > > >