[wpkg-users] [Bug 91] Do not execute wpkg.js on a slow network connection

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=91


Twan Fox <twanfox at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |twanfox at gmail.com




--- Comment #11 from Twan Fox <twanfox at gmail.com>  2007-12-10 23:05:57 ---
Are there many cases in which this would be noticable? Perhaps not. However,
you should consider a few cases to determine the worth of such a feature.

1) Large package deployments (Service Packs, MS Office, Open Office, etc..)

Not doing download before installation drags the installation to a crawl. Case
in point, even via SMS, a deployment of XP SP2 direct from network took ~2
hours in some cases, when a local install took 30 minutes at most. I don't even
want to think of what happened to server-side bandwidth during that time.

2) Interruptions

If you have a long install period due to slow link, big package, etc, you will
find users interrupting it via disconnecting from the network, shutting down
their workstations, or similar. If we're just taking the time to download the
package, then we can restart from the last block we downloaded and spend the
least ammount of time doing the actual install.

3) Enhanced Delayed Deployments

With added features in the WPKG Client and script, a delayed install can be
downloaded at leisure and, even when off the network, installed when the
install time comes and goes. This can prove useful for patch installs where you
offer it to workstations, laptops and such, they download it as a trickle
through the day, and whenever they come online next, it sees the time is past
and installs. This enhances availability to deploy those packages.

Those are the biggest cases I can see in which download-then-deploy would be
useful. Would it be required all the time? No, certainly not. However, like
everything, availability of the feature gives one more tool in the belt.

Point #2 you raise is, to me, more of a problem outside the realm of WPKG. If
an app's installer isn't smart enough to roll back changes during install when
it fails, how can WPKG change that? However, in case #2 above, if all we were
doing was downloading the package and not installing it over a slow link, we
save what we got (a la robocopy-type resumable file copy) and try again later.

Though, I fear, I've rambled off topic of the request :(


-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

-------------------------------------------------------------------------



just about anything Open Source.
http://sourceforge.net/services/buy/index.php
-------------------------------------------------------
Easy Software Deployment >> http://wpkg.org
_______________________________________________
wpkg-users mailing list
wpkg-users at lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users