ReL Many Cards Versus One Card and a List Field

[Richard Gaskin]

Mikey wrote:
> Richard,
> Obviously others have commented on the patent.  If the patent hasn't
> expired, it is about to, and the technique will be described in the
> patent application.
> 
> Regardless, there is nothing that stops anyone from circumventing a
> patent by reverse-engineering it, which is generally the favored
> technique.

Of course, as noted in my post:
<http://lists.runrev.com/pipermail/use-revolution/2008-January/106068.html>

I realize it got a bit long, but where I noted the patent I also noted 
that it was the lesser of at least two reasons it would seem unlikely 
that the folks at RunRev would pursue a data storage solution dependent 
on a single representation of content.

> Finally, the argument that "everyone else is doing" something would
> have led to HC never being created in the first place.  Paradigms are
> made to be broken.

While I'm all for innovation, it's balancing act.  Sometimes the entire 
world isn't wrong.

The HC paradigm was fun and useful, but it was also unique and is now 
extinct.

For all these years, it's noteworthy that while so many other products 
have been inspired by HC's innovative visual programming approach (a 
former Microsoft employee once told me that Visual Basic was prototyped 
on a Mac with SuperCard <g>), none of them have seen it worthwhile to 
also replicate its approach to data storage.

That said, there may still be merit to that approach, and perhaps 
FileMaker's Bento offers the closest match among modern tools to 
accommodate a similar set of needs.

My point is not whether it has any merit, but rather the likelihood of 
Rev adopting it in a world where the remaining growth opportunities must 
address an audience who's never seen HyperCard before, but probably has 
at least some familiarity with any of the variety of systems which 
separate layout from content.

In short, Rev may be different from HyperCard, but I don't think it's 
fair to characterize that difference as "broken".

Case in point:

Many years ago I helped port a card-based system in HC to Rev.  The 
final product was at least semi-relational in parts, and those that were 
saw a three-orders-of-magnitude performance gain; a process that once 
ran all night in HC is now completed in just a few minutes in Rev.

It didn't use Valentina, or MySQL, or anything externals at all.  Just 
delimited data in custom properties, all in native Transcript.

Moreover, the user interface could be enhanced at any time without 
affecting the client's data.  No cumbersome export/import; just drop the 
new UI stacks in and new features become available instantly.

This isn't all that novel; most apps do this.  We didn't invent any new 
paradigms, just used existing ones to the user's advantage. This morning 
I updated my iTunes, and it didn't touch my data at all.  Same with 
upgrades to everything from Adobe GoLive to Microsoft Word.

Separating content from presentation is simply a paradigm that works, 
and I can't fault the folks at RunRev for focusing on providing 
solutions which favor it.

Sure, it's more work for the developer.  Most things that make life 
easier for the end-user are.  So we just roll up our sleeves and make 
magic, and all the user knows is that their world is a little bit 
simpler than it was the day before.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com