External functions

[Eric Chatonet]

Hi Trevor,

I ran into the same questioning :-)
The way I chose is the following:
The app/exe itself is, of course, a launcher.
This launcher retrieves information from an external splash stack  
and, among others, allows to set the label of the exe with the right  
version number.
A very simple text file on our server allows to compare automatically  
the user current version with the last one and alert him if needed.
When an update is available, needed files are downloaded and the  
external splash screen is always replaced.
In case of 'big' update, a process allows with an invisible installer  
to update all files, exe included and restart the software.
In addition, a check at every launch, verifies if all needed files  
are there and downloads missing ones from the internet if needed.
So, in a few words, we have to ways of updating: a light one when  
replacing a stack file or another one that replaces the whole app.
PS. For security, all files on disk are ciphered and restored in RAM  
on-the-fly.

Le 4 févr. 08 à 18:23, Trevor DeVore a écrit :

> On Feb 4, 2008, at 11:38 AM, Eric Chatonet wrote:
>
>> In complex projects that are known as needing future upgrades, I  
>> prefer to have libraries, externals, pieces of the GUI, etc. in  
>> specific folders.
>> Then, any component can be easily updated from the web when needed.
>> My two cents ;-)
>
> Eric, your mention of updating an app over the web and organizing  
> individual pieces into their own separate folders brings to mind  
> some issues I've been thinking about recently in regards to auto  
> updating. So in the interest of sharing some additional thoughts on  
> the subject of auto updating, here they are.
>
> When I originally implemented auto updating in one of my  
> applications I would create updates that only updated specific  
> stacks in the installation. I thought it was really cool that  
> Revolution could update any stack on the fly and then just reload  
> without restarting the application. That application has been  
> around for a number of years now and has received numerous updates.
>
> What I found was that this approach ended up being more complex  
> then I would have liked as I had to determine which stacks had been  
> changed since the last version and then only include them in the  
> update I pushed out.
>
> I decided I wanted an auto update architecture that required as  
> little thinking as possible come publish time. Add some release  
> notes, click a button and upload the files. I didn't want to have  
> to keep a log each time a script changed anywhere in a stack so  
> that I would remember to update it when I pushed out the next  
> version. I also wanted to have an exact snapshot of every file in  
> the installation for each release so that I could be look at the  
> exact same code that was running on the end-user machine if they  
> report a problem with version 1.2.3.
>
> So when I revised my auto update architecture I designed it so I  
> could push out:
>
> a) new program files (stacks, externals, supporting docs, etc.) or
> b) just the executable files (to push out engine bug fixes) or
> c) both a and b.
>
> This was much simpler to deal with on my end and it made me feel  
> good inside that I wasn't making the user download the ~2MB engine  
> each time if they didn't need to. Since I was no longer updating  
> the application at the stack level I wasn't as concerned with  
> splitting up stacks into different files on disk.
>
> I've now been using this update architecture for a little over a  
> year now. Over that year I've seen a number of users write in  
> thinking that they weren't running the latest update because the  
> File Info dialog for the executable said 1.x instead of 1.x.x (The  
> about box does report the proper version though).
>
> So now I'm of the mind to always update the entire application  
> whenever I push out a new public release for a consumer  
> application. I can still provide the benefit of the app updating  
> itself and relaunching with no intervention and there is less room  
> for confusion as to what version they are running since the File  
> Info dialog for the executable reports the proper version. I figure  
> a couple of extra seconds (or minutes depending on connection  
> speed) to download everything is worth it in the end.
>
> Regards,
>
> -- 
> Trevor DeVore
> Blue Mango Learning Systems
> www.bluemangolearning.com    -    www.screensteps.com
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



Best regards from Paris,
Eric Chatonet.
----------------------------------------------------------------
Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: eric.chatonet at sosmartsoftware.com/
----------------------------------------------------------------