Auto-update architecture on Windows...dealing with bulk
andre at andregarzia.com
Tue Jul 3 09:23:53 CDT 2007
the solutions to this are many, I'll tell you what my current approach is.
First minimal loader, no code or elements but the ones needed for loading
the mainstack and a possible version check of the loader itself that may
prompt the user to download a new loader in case you need an updated engine.
The problem is what to do when the user is not connected or how to deploy
that application in non networked environments.
What I do is that I have a library here that "downloads & cache" my files,
so if there's no connection, I simply loaded the cached files, if there's a
connection, I check versions, if they are the same, I load the cached
versions, I only try to update in the case there's a network and an update
available. So to distribute on CD, I can simply include the cached files
folder (actually, you need to put some check to see if you can write to disk
before attempting an update, I haven't tackled the problem of cds yet).
so you can load more than one stack over the network, I work with a "bill of
materials" stack that has a list of downloadable components and their
versions. you can put all your art in a single stack and the code in other,
this way you can update code without updating huge art stacks. Compressing
the stacks is a wise decision because saves bandwidth.
On 7/3/07, Mark E. Powell <runrev at aboutmyfiles.com> wrote:
> On Windows, and am using the auto-update architecture, i.e. a compiled
> auto-loader app that pulls non-compiled main stack updates from the
> network. I have two questions that I would like advice on.
> How to optimize the bulk: Given that the auto-loader should avoid having
> to update itself, and given then that the main stack constitutes the baggage
> that has to be schlepped around, does it not make sense to remove hefty and
> unlikely-to-change elements from the main stack and put them into the
> auto-loader? For example, UI image elements that add a lot to the file size
> of the main stack could instead be anchored in the auto-loader. In other
> words, what are the ramifications to me saying:
> "If element X will not change, put it into the auto-loader half."
> How do I distribute this architecture on CD, without requiring that the
> user be connected to the network. In the non-CD delivery, I state that
> first use requires connectivity. But I would like the ability to provide
> the entire thing on disk as well. Do I need an installer that wraps
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode