Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!csn!datran2!smb From: smb@data.com (Steven M. Boker) Newsgroups: comp.sys.next Subject: Re: call for built in IB documenter Message-ID: <1991Mar20.183758.2741@data.com> Date: 20 Mar 91 18:37:58 GMT References: <69158@brunix.UUCP> <1991Mar20.165430.2364@data.com> Organization: Data Transforms, Inc. Lines: 25 In article cnh5730@maraba.tamu.edu writes: >In article <1991Mar20.165430.2364@data.com> smb@data.com (Steven M. Boker) writes: > Those at NeXT who > are reading this should take note. Implementing Ronalds idea would > be a boon to the more-than-casual developer. > >Why not write an IBdocument.app and implement Ronald's idea your self? >Your app could interface with IB seamlessly if you implement the app using >NeXT's "services" paradigm. The basic problem with a third party IB scripting language is that it doesn't have the "standards" power that a release from NeXT would have. I agree that if NeXT decides that it has no intention of producing such a .nib scripter, a third party would have a hot product here. However, any release from NeXT would blow a third party away. Its a good idea, but a dangerous one from an investment standpoint for a third party developer. Steve. -- #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====# # Steve Boker # En Vino Kaos # # smb@data.com # En Kaos Veritas # #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#