Jim Bufalini wrote:
OK... time for a dumb question. What kind of application would have 5,000 or
10,000 cards? Is it because the application is using cards to hold records
of data instead of using a database? Otherwise, I can't even imagine it.
Also, wouldn't an application with a stack with this many cards be a huge
memory hog?
The problem is that you've been making software too long. :)
If you've ever shipped a version 2.0 of something, you realize very
clearly the traditional benefits of separating code, UI, and content, so
you can enhance the UI without affecting the user's data.
But HC made it very convenient to store data on cards, and out of the
box provided no way to work with any database at all (SQLite hadn't even
been invented yet).
Bill Atkinson said more than once that "HyperCard is not a database",
but the convenience of using it as one encouraged people to do so.
Memory wasn't an issue, because HC paged from disk. Remember, it was
designed to work in early Macs, back when 2 GB of RAM was an
unimaginable dream. Paging from disk meant only a limited number of
cards were in memory at any given time (though the frequency of 5454
errors -- file corruption -- told the other half of the story, the
inherent complexity and potential brittleness of paged systems for
anyone who didn't make a religion of compacting regularly to rebuild the
file).
So flash forward: 20 years later, HC has been dead for more than a
decade, Rev is growing, and there are a lot of legacy systems built in
HC looking for a new home.
But as you know, Rev loads the entire stack file into memory at once,
which gives it a certain robustness and contributes to its excellent
performance, but means that storing 20,000 cards in a stack just isn't
practical.
Dr. Raney was nothing if not pragmatic, so optimizing his structures to
accommodate that many cards was not something he ever bothered to invest
time in because it only encouraged people to things that would lead to
other problems down the road (like making a v2.0 that enhances one's UI).
So this means that while Rev's support for the HC file format makes it a
good choice for porting legacy HC stacks, in many cases those stacks
need to be restructured to make good use of it. This often means very
fundamental changes, like moving the data out of the UI, which are
unintuitive for someone coming from a system where that wasn't needed.
I believe there are so many benefits in separating code, UI, and content
that it's well worth the effort, and the clients for whom I've ported
large HC stacks have been pleased with the results Rev offers.
But I also recognize it's a bit of a head-scratcher when you do it for
the first time.
--
Richard Gaskin
Fourth World
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
