Heh heh heh, we do the identical thing. :-) ----- Original Message ----- From: "Paul Heinz" <[EMAIL PROTECTED]> To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]> Sent: Monday, 2 September 2002 12:41 PM Subject: RE: [DUG]: Location of EXE
> Eion wrote: > > > We have done that here with a couple of apps. The only things you > > have to look out for is when trying to update it with a new version, > > no user can have it running at the time. > > > Mark wrote: > > > > > Are there any Gotcha's in putting a single application .exe file on > > > a server and allowing multiple users to fire it up from there? > > That last issue can be a real hassle, especially as the user count climbs. > Also, you have the issue that the code pages are moving across the network > and consuming precious bandwidth (if only every client had switched 100BaseT > with GigE from switch to Fast Wide Ultra SCSI-3 servers :-) and also > consuming file memory cache on the server which could otherwise cache > valuable data. We try to keep our applications fairly slim and svelte but > nothing beats the performance of I/O you didn't have to do :-) > > So, in response to your resllers comments, we developed a utility called > LaunchGuard which offers a hybrid approach combining the best of both worlds > IMO (i.e. centralised updates but local cacheing). > > The core idea is that on launch the application checks a central location > (i.e. the server) for any updates and pulls them down to a cached client > copy. The up-to-date client copy is then launched. This is all largely > invisible to the user - they just click the application shortcut as usual. > Also, all the LaunchGuard infrastructure is put in place automatically as > part of the initial (and only!) client application installation and the > server application installation. > > Now, I'm not claiming this is a radical or new idea - the internet update > checks many modern applications use (e.g. some net games, anti virus > software) is the same technique. As always, the devil is in the fiddly > little details (as Wil, the main developer can confirm at length :-), but > that's the basic concept. > > It makes it very easy now for our resellers to update client sites, > especially when there is in excess of 30 possible PCs accessing the > application (including the ones that got added without their knowledge :-) > Each client cached copy will automatically update as the user goes to launch > the application. You can't get 'stale' or mismatched clients (often the bane > of database applications). > > For anyone deploying applications where they expect regular updates to be > supplied (due to either new features, requirements changes, or even <gasp> > bugfixes) and user counts are expected to often exceed 3 or so, I'd really > recommend exploring this technique. > > TTFN, > Paul. > > > -------------------------------------------------------------------------- - > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] > Website: http://www.delphi.org.nz > To UnSub, send email to: [EMAIL PROTECTED] > with body of "unsubscribe delphi" > Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ > > --------------------------------------------------------------------------- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
