External functions

[Trevor DeVore]

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