Upgrading Substacks Only

Monte Goulding monte at sweattechnologies.com
Wed Apr 30 19:15:01 EDT 2003

Hi Jim

One of the projects I'm working on at the moment includes exactly what your
talking about. From what I can see you need to handle a number of
- upgrade a mainstack
- upgrade or create a new substack
- upgrade or create a new stack file
- upgrade or create a new file

You may want to be able to copy some properties from the existing stack to
the new stack. You also need to ensure that users download and install all
upgrades in the correct order or make each upgrade a combined upgrade since
the initial release.

I can't see any problems with the approach with the exception of the
HyperCard style database where each record is stored on a card. Seeing as
that's not a good way to do things in Rev I don't think it would be a huge



> -----Original Message-----
> From: use-revolution-admin at lists.runrev.com
> [mailto:use-revolution-admin at lists.runrev.com]On Behalf Of Jim Biancolo
> Sent: Thursday, 1 May 2003 5:42 AM
> To: use-revolution at lists.runrev.com
> Subject: Upgrading Substacks Only
> Hi folks,
> I was trying to figure out the best way to create an upgradable
> standalone
> Rev app.  In toying with ways of separating data from presentation I
> noticed that when I build a distribution that has separate substacks, the
> main executable is around 1.5MB (on Windows) while the substacks are much
> smaller.  This is true even when my mainstack is just a dummy stack that
> invokes one of the substacks on startup.  This got me to wondering if I
> could distribute the standalone EXE (and mainstack) as the
> engine, and then
> just the substacks during upgrades?  This would greatly reduce the
> bandwidth needed in distributing upgrades, it seems.
> I did a successful test of this approach, but I'm wondering if there are
> any downsides I'm not seeing?
> Thanks!
> Jim
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution

More information about the use-livecode mailing list