Auto-update architecture on Windows...dealing with bulk

Andre Garzia andre at
Tue Jul 3 11:23:41 EDT 2007

I am no expert on such issues but my best answers are:

-1- You can bundle a copy of your main stack with your installer, so you
have an environment with all the needed files for the first run.
-2- The way I do is using "order of download", dependencies are downloaded
before the stuff that depended on them. Since I use a queue of files to be
downloaded, that ensures that when something has a dependency, that file
will already be in place when the actual file arrives. As for versioning, I
don't have much experience on versioning different components, I usually
just change mainstack and libraries, I keep them all with the same version
number. I though of this architecture but I didn't needed it yet. You need
to keep a clear architecture, if your mainstack depends on three other
library stacks, two of which are updated, you simply download them and
control the release using the BOM. I cache the BOM file too, so for a given
release, I know all the files and all the versions, if something is wrong, I
just need to fetch the files again.

Caching the BOM files also allow you to rollback to any version you want,
it's just a matter of downloading the files again. For this to work, you
need to make all the files available, so you can use folders on your server
for example


So for a given release, you have all your metadata on a BOM file and a
server that is organized to allow you to download any release at will. This
architecture allows for simple versioning and remember since you're loading
stacks, you can use preOpenStack or something to check for further

what about this?


On 7/3/07, Mark E. Powell <runrev at> wrote:
> Hi Andre:
> Good information.  Couple of more questions:
> -1- On first use, do you require connectivity in order to cache the main
> stack?  I assume yes, right?
> -2- In the BOM stack approach, how do you control versioning and
> dependency?  (i.e. resource stack X must be downloaded with widget Y,
> otherwise the app doesn't operate).  Is there a best practice on how to
> avoid mismatches with 'modularized' main stacks?
> Thanks,
> Mark
> _______________________________________________
> use-revolution mailing list
> use-revolution at
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:

More information about the Use-livecode mailing list