Joshua --

Ted Kaehler has done quite a bit of work with this (because SqC has done
what you suggest below for several years now). Most morphs (and now whole
projects) are pretty flexible under many kinds of updates.
     As to the possibility of a "barrier" between a qualitative change
between old and new, that will depend on whether the "new" is good enough
to merit a discontinuity. Since we are still discussing these issues and
don't yet have any "new" prototypes to even experiment with, there is quite
a bit of time left before this even becomes an issue. (However, I sense
that you could be a factor in moving towards the new ...).

     One of the ideas we have been experimenting with is that for simple
things users should be able to construct graphic entities directly without
having to think of views (this is kind of like HyperCard). However, there
are many cases where having mulitple views/filters is desirable, and (again
kind of like HyperCard) one should be able to easily construct a graphic
object that views another.
     For the next level of viewing sophistication, MVC falls short, and one
would like a more meta approach to viewing that actually treated views as
aspects of objects (I wrote a paper about this in 1980 or so. If I can find
it, I'll send you a copy).

Cheers,

Alan

------

At 5:16 PM -0800 4/16/00, Joshua Gargus wrote:
>Hi there,
>
>In my recent experimenting with my organizer, I have been storing a fair bit
>of information as Morphic objects (books, sketchs, animations, etc.)
>When Morphic is revamped, will these existing morphs be usable in the new
>version, or will there be an OldMorphic/NewMorphic barrier akin to the
>MVC/Morphic barrier we have in the current image?
>
>If the latter is the case, how difficult do you anticipate that it would be
>to write code to convert from one format to the other?
>
>On a related topic, does anyone have any thoughts about storing morphs as
>data rather than as a View on data?  Using them as the data itself is
>certainly appealing, simply because of the sheer flexibility and
>expressiveness of the medium.  Are there any reasons why you would want
>to use a model-view separation instead?
>
>Thank you for considering these questions,
>Joshua
>--