App Framework - Stance 1

[UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,BDV)]

Friends,
 
I am enjoying this lively debate regarding MCL application frameworks, and am
delighted that it (and OODL SIG) could not have come at a better time, what
with Bedrock and MacApp futures and Dylan, etc.  Could I offer an integrative
suggestion to guide us from hereon:
 
1.  Different MCL users have different requirements.
 
2.  Some folk are clearly most concerned about cross-platform portability, and
I think that the two possible paths then open are:
    a.  CLIM - support for CLIM form MCL is clearly very important.  I hope
that both CLIM vendors and MCL policy determiners are hoisting in that there
*is* real demand for this, and that many people in the MCL community would like
the bond to grow firmer, to the extent of a formal announcement and formal
support.
    b.  Bedrock - whether CLIM 3.0 is modelled after Bedrock (in terms of
functional ability) or Bedrock becomes accessible from MCL is a moot point
which time alone will tell.  But *if* Bedrock takes off successfully, some form
of functional compatibility with it would seem to be very important.  There is
little point in OODL SIG trying to move resources into this for a good while
yet, but we should watch and take note.  Personally, I think that trying to
access Bedrock (in C++) from MCL is neither a wise move nor an easy one, but
only time will tell.
 
3.  Some folk are concerned at being able to develop shrink-wrapped
applications which are strong on Mac features.  There are a number of
possibilities again:
    a.  MCL - this is with us here and now, and (although it is perhaps not
quite as nice as we might wish) we should work to support it early.  Waiting
for Bedrock, or Dylan, will cost MCL, and I for one need a decent MCL
application framework *today* not next year.
    b.  Dylan - yes, I agree that this is much more likely to be good at
producing shrink-wrapped apps, and hopefully we will not have much longer to
wait before we can start working with it.  If we do an app framework right for
MCL, it should stand us in very good stead for Dylan - indeed, perhaps in some
areas (exception handling, for instance) we can actually use Dylan's model to
enhance MCL's application library.
    c.  C++ - if you want to do this, then feel free, but I do not think that
OODL SIG should be overly concerned with trying to oblige you!  Maybe you want
to prototype your interface with MCL, in which case if we choose a good
interface designer (like AppMaker), then we should make the C++ development a
bit easier.  But trying to support your translating MCL to C++ I think is a bit
much, at least for now.
 
4.  I have not mentioned Garnet.  I notice from recent postings that Garnet
does *not* use CLOS, which I consider to be essential to our application
framework, and that it is cross-platform (being fairly heavily Motif-oriented).
By all means let someone in the community help finish off its porting, but I do
not think that it addresses the needs of those of us after shrink-wrapping this
year.
 
5.  That Apple's resources are better devoted to improving MCL and launching
Dylan, and that Apple is happy for members of OODL SIG to work on this
application framework (without making our efforts redundant too quickly!)?
 
Is there support for this, or can we not reach a consensus from which to work?
 
Howard.