From kc Wed Apr 9 00:11:24 1997 Return-Path: Received: from criamon by omnigroup.com (NX5.67f2/NX3.0M) id AA06025; Wed, 9 Apr 97 00:11:24 -0700 Message-Id: <9704090711.AA06025@omnigroup.com> Received: by criamon.omnigroup.com (NX5.67g/NX3.0X) id AA00383; Wed, 9 Apr 97 00:11:24 -0700 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Image-Url: ftp://ftp.omnigroup.com/pub/Images/People/kc.tiff X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ken Case Date: Wed, 9 Apr 97 00:11:23 -0700 To: omninews, rhapsody-dev, rhapsody-talk Subject: New Rhapsody mailing list: rhapsody-talk@omnigroup.com Reply-To: kc@omnigroup.com X-Url: http://www.omnigroup.com/People/kc/ X-Organization: Omni Development, Inc. I've created the rhapsody-talk@omnigroup.com mailing list, where general discussions of Apple's Rhapsody operating system are welcome. Those interested can find more information about the list at: http://www.omnigroup.com/MailArchive/rhapsody-talk/ Or you can just subscribe directly by sending email to listproc@omnigroup.com saying: subscribe rhapsody-talk Your Name I'm hoping that the signal to noise ratio on this list will remain high, but the definition of what is "signal" on this list is much more broad than it is on the rhapsody-dev mailing list. Enjoy! Ken From indy@gryphon.com Wed Apr 9 04:52:00 1997 Return-Path: Received: from empire.is.com by omnigroup.com (NX5.67f2/NX3.0M) id AA07767; Wed, 9 Apr 97 04:52:00 -0700 Received: from gryphon.is.com by empire.is.com; Wed, 9 Apr 1997 06:51:51 -0500 Received: by gryphon.is.com (NX5.67f2/NX3.0S) id AA00344; Wed, 9 Apr 97 06:48:52 -0500 Message-Id: <9704091148.AA00344@gryphon.is.com> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.118.2) From: Steve Weintz Date: Wed, 9 Apr 97 06:48:50 -0500 To: rhapsody-talk@omnigroup.com Subject: Introduction - Steve Weintz Cc: rhapsody-dev@omnigroup.com Reply-To: indy@is.com Yo! I'm cross-posting this message once; I'll sort out further = missives based on topic. Good to see so many familiar names! I've been a NeXT user since early 1993 (around Black Tuesday, in = fact!) At the time I was in grad school at the University of = Illinois, and the only UNIX machines the unwashed could get an = account on were the black boxes. As happend, I became interested = in 3D graphics at the time and was blown away by the magic of = Workspace Manager and the 3DKit. I dropped out of grad school, = bought a Turbo NeXTdimension and holed up in my apartment for = several months of dire poverty learning RenderMan. Four years later, after stints as a freelance artist and an art = director and webhead for one of the first Web magazines, I'm a = successful graphic designer at a Minnesota NeXTSTEP/OpenStep = software firm and regularly participate in graphics and RenderMan = discussions. Because i was able to teach myself UNIX, RenderMan, = and digital illustration within NEXTSTEP's friendly environment, I = found myself able to work at the Beckman Institute Visualization = Lab (one floor down from NCSA!) and get interviews at Disney, = Warner Bros., and other studios. I've long claimed that NEXTSTEP is the superior content-creation = platform, and if it had MacOS's depth of software it would be = heaven. Lo, my prayers have been answered! I'm ablaze with ideas about what I could do with Photoshop if it = had the power of TIFFany 2, a Premiere within a multitasking = environment, a solidThinking with a market of millions. I'm hoping = to expand my digital studio to produce short 3D animated films, = and am eager to build a Rhapsody/NeXTSTEP production environment. Do these lists support MIME? --- Steve Weintz * indy@is.com * Graphic Designer, Integrity = Solutions, Inc. = --------------------------------------------------------------------= ---------- When confronted with vastly intelligent, aggressive politics, do = something=20 totally irrational and let the enemy think himself to death. -- = P. Chanur= From uucp@cubiculum.com Wed Apr 9 13:37:08 1997 Return-Path: Received: from tunix.cubiculum.com by omnigroup.com (NX5.67f2/NX3.0M) id AA15345; Wed, 9 Apr 97 13:37:08 -0700 Received: by cubiculum.com (NX5.67f2/NX3.0M) id AA28082; Wed, 9 Apr 97 16:36:18 -0400 Received: by kannix.cubiculum.com (NX5.67g/NeXT-2.0) id AA03022; Wed, 9 Apr 97 16:34:41 -0400 Message-Id: <9704092034.AA03022@ kannix.cubiculum.com > Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Face: B6DESMpZ'<"P]D0{Aaq$#h/PfN=wI.C{,&<2_;#|.("xO+oeVic@@=zI2zD#NR~S#l*OV}[ X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ronald C.F. Antony Date: Wed, 9 Apr 97 16:34:38 -0400 To: rhapsody-dev@omnigroup.com, rhapsody-talk@omnigroup.com, misckit@yacktman.com, eof@omnigroup.com, next-prog@omnigroup.com, webobjects@omnigroup.com Subject: RenderMan petition Reply-To: "Ronald C.F. Antony" X-Direct-Marketers: : Add me to your do-not-solicit list I think the following is of interest to all here. Make your voices heard. If someone else posted this here already, I apologize for the waste of bandwidth. Ronald Begin forwarded message: From: Thomas Engel Date: Wed, 9 Apr 97 21:10:24 +0200 To: g3dkit@immd9.informatik.uni-erlangen.de Subject: RenderMan petition Hi. For those who would like to see RenderMan bundled with (or at least offered for) Apple's new Rhapsody OS please sign the official petition which has been set up at: http://www.webnation.com/petition/index.html Aloha Tomi From ernest@alumnae.caltech.edu Mon Apr 14 13:18:20 1997 Return-Path: Received: from alumnae.caltech.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA28242; Mon, 14 Apr 97 13:18:20 -0700 Received: (from ernest@localhost) by alumnae.caltech.edu (8.8.3/8.7.3) id NAA10653 for rhapsody-talk@omnigroup.com; Mon, 14 Apr 1997 13:18:11 -0700 (PDT) Date: Mon, 14 Apr 1997 13:18:11 -0700 (PDT) From: "Ernest N. Prabhakar" Message-Id: <199704142018.NAA10653@alumnae.caltech.edu> To: rhapsody-talk@omnigroup.com Subject: Developer communication Okay, somebody suggested the recent SJ merc thread should move here, so let us do so. Perhaps if we used this (-talk) the way it was meant, people would leave -dev alone. Remember, unsubscribe if you don't want to chat about this stuff. So, help me out here. As a NeXT-head, I think NeXTSTEP, er, OpenStep, er Rhapsody is the greatest development environment in the world, and anyone who has any aspirations of creating cool software would fall over them- selves to developer using it. Obviously, I am not the entire marketplace. So, what are people's concerns? The only thing that bugged me about the SJ merc article was that it seemed to ramble about the various problems, rather than carefully define them. Is the problem: - Not knowing what the strategy is - Not believeing Apple can execute it - Not thinking it will help even if Apple does what they claim What are people concerned about? - their pet technologies (e.g. Game Sprockets) - costs/distribution of developer tools - licesning of the runtime for Windows - migration assistance (e.g. Latitude) There are a variety of feedback channels that appear to exist, and at least some Apple people regularly hang out int he newsgroups. Maybe I'm naive, but perhaps if we (as a developer community) could clearly articulate what we want, Apple might do a slightly better job of addressing it. Is this already happening somewhere else? Have people given up trying to tell apple what they want, so they just tell the newspapers how annoyed they are? Is their no coordinated user group or developer advocacy for presenting "demands" (or at least issues)? -- Ernie P. From adul@cmg.FCNBD.COM Mon Apr 14 14:14:52 1997 Return-Path: Received: from po-external.FCNBD.COM by omnigroup.com (NX5.67f2/NX3.0M) id AA28745; Mon, 14 Apr 97 14:14:52 -0700 Received: from po-internal.FCNBD.COM (internalhost.FCNBD.COM [147.113.104.10]) by po-external.FCNBD.COM (8.8.5/fcnbd/domain/1.5.1) with ESMTP id QAA21925 for ; Mon, 14 Apr 1997 16:20:30 -0500 (CDT) Received: from abacab.cmg.FCNBD.COM (abacab.cmg.FCNBD.COM [147.113.112.11]) by po-internal.FCNBD.COM (8.8.5/fcnbd/internal-domain/1.4.1) with ESMTP id QAA07313 for ; Mon, 14 Apr 1997 16:16:14 -0500 (CDT) Received: from falstaff.cmg.FCNBD.COM (adul@falstaff.cmg.FCNBD.COM [147.113.112.147]) by abacab.cmg.FCNBD.COM (8.8.5/fcnbd/server-subdomain/2.3) with ESMTP id QAA18231 for ; Mon, 14 Apr 1997 16:14:41 -0500 (CDT) Received: (from adul@localhost) by falstaff.cmg.FCNBD.COM (8.7.3/8.7.1) id QAA06779 for rhapsody-talk@omnigroup.com; Mon, 14 Apr 1997 16:14:38 -0500 (CDT) Message-Id: <199704142114.QAA06779@falstaff.cmg.FCNBD.COM> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) In-Reply-To: <9704142020.AA28312@omnigroup.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 2.0b5) Received: by NeXT.Mailer (1.118.2) From: Albert Dul Date: Mon, 14 Apr 97 16:14:30 -0500 To: rhapsody-talk@omnigroup.com Subject: Re: Developer communication References: <9704142020.AA28312@omnigroup.com> It's been rumored that Ernest N. Prabhakar said: > There are a variety of feedback channels that appear to exist, and at > least some Apple people regularly hang out int he newsgroups. Maybe I'm > naive, but perhaps if we (as a developer community) could clearly > articulate what we want, Apple might do a slightly better job of > addressing it. Is this already happening somewhere else? Have people given > up trying to tell apple what they want, so they just tell the newspapers > how annoyed they are? Is their no coordinated user group or developer > advocacy for presenting "demands" (or at least issues)? > > - -- Ernie P. A while ago there was just such an organization formed, called AIMED, for the Association of Independent Macintosh Engineers and Developers, at . I haven't seen much from them in a while, but they are officially incorporated (AIMED is a nonprofit corporation under IRS category 501(c)(3)) and have some kind of infrastructure in place. This is their charter, in its entirety: "To organize a large body of Macintosh developers to: * Provide a voice to the press and public about the current state of Macintosh Development. * Provide a voice to Apple about Apple's directions from a developer point of view. * Help isolate gaps in Macintosh software needs and get them filled." Maybe if enough folks rattled their cage a bit, things could get hopping again. Albert Dul --- Hm: aldul@concentric.net "This might not look as obvious to the 40 or 50 people who've never seen it before." From sanguish@digifix.com Mon Apr 14 14:29:15 1997 Return-Path: Received: from digifix.digifix.com by omnigroup.com (NX5.67f2/NX3.0M) id AA28928; Mon, 14 Apr 97 14:29:15 -0700 Received: (from sanguish@localhost) by digifix.com (8.8.5/8.8.5) id RAA21631 for rhapsody-talk@omnigroup.com; Mon, 14 Apr 1997 17:29:30 -0400 (EDT) Message-Id: <199704142129.RAA21631@digifix.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.1mach v148) In-Reply-To: <199704142018.NAA10653@alumnae.caltech.edu> X-Nextstep-Mailer: Mail 4.1mach (Enhance 2.0b5) Received: by NeXT.Mailer (1.148) From: Scott Anguish Date: Mon, 14 Apr 97 17:29:30 -0400 To: Multiple recipients of list Subject: Re: Developer communication Reply-To: sanguish@digifix.com References: <199704142018.NAA10653@alumnae.caltech.edu> Dr. Ernie wrote: > - Not knowing what the strategy is > - Not believeing Apple can execute it I think this is a particularly nasty problem for many jaded Apple developers. Apple has fallen flat on its face over the last 7 years or so, releasing very late or very buggy implementations. Rhapsody as it will be, is alot more stable NOW, useable NOW, and tangible NOW than Copland ever was. OpenStep has been deployed for a while now, and people have been using it and developing for it. You can see what Apple will have available in a short few months NOW with OpenStep 4.2. In three weeks, you can see Rhapsody at the WWDC, and shortly after that, run it on your PPC. > - Not thinking it will help even if Apple does what they claim If you've lost faith in the market (which is where this seems to lie) then nothing Apple tell's you will make a difference. You'll have to wait and see. >What are people concerned about? > - their pet technologies (e.g. Game Sprockets) Many of the MacOS technologies (like Game Sprockets) will have similar Frameworks in Rhapsody. Even if they are not currently spelled out, I've got faith in the NeXT people that things will be there, and hopefully integrated in a very useable and tight manner. I'd like to see more MacOS developers say what they need as the end result instead of that they want Sprockets or CyberDog or AppleScript) In this case it would be - fast access to Video/Sound via Frameworks - re-useable Internet App Frameworks and to ship with lightweight Internet Apps for users - an extendable scriptable AppKit (not as hard as it sounds) > - costs/distribution of developer tools I think this is pretty important. I HOPE Apple gives OS 4.2 away at the Developers Conference to attendees. At least in the short term Apple needs to grab some mindshare of the developers. > - licesning of the runtime for Windows This is something that Apple MUST ADDRESS. The SOONER THE BETTER. The problem here is that those who have bought into the Rhapsody future still don't have the details on this final bit of NECESSARY information. > - migration assistance (e.g. Latitude) From gad@eclipse.its.rpi.edu Mon Apr 14 17:44:00 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA02673; Mon, 14 Apr 97 17:44:00 -0700 Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id UAA97382 for ; Mon, 14 Apr 1997 20:43:52 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA26853; Mon, 14 Apr 97 20:43:51 -0400 Message-Id: <9704150043.AA26853@eclipse.its.rpi.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Mon, 14 Apr 97 20:43:49 -0400 To: Multiple recipients of list Subject: Re: Developer communication References: <199704142018.NAA10653@alumnae.caltech.edu> > Okay, somebody suggested the recent SJ merc thread should move > here, so let us do so. Perhaps if we used this (-talk) the way > it was meant, people would leave -dev alone. Remember, unsubscribe > if you don't want to chat about this stuff. I think it is a good idea to move the discussion to this mailing list. > The only thing that bugged me about the SJ merc article was that > it seemed to ramble about the various problems, rather than carefully > define them. Is the problem: > - Not knowing what the strategy is > - Not believeing Apple can execute it > - Not thinking it will help even if Apple does what they claim I think the main problem falls into the "Not knowing what the strategy is". Sure, we have the grand, sweeping outline of what it will be, but there are a lot of details which people don't know yet. When they ask Apple about it, right now they get a lot of "Wait until the WWDC". There may be very good reason for Apple to say that, but it's still a bit disconcerting. > What are people concerned about? > - their pet technologies (e.g. Game Sprockets) At this point most of the people know how their pet technologies have fared. Probably the biggest "if" would be the details around the Game Sprockets technologies. We know that there will be "something", but we have to wait to find out exactly what that "something" is going to look like. I, personally, am not too worried about Game Sprockets. I suspect Apple will cover that issue quite well, once they get around to telling us the details. > - costs/distribution of developer tools > - licesning of the runtime for Windows > - migration assistance (e.g. Latitude) Costs are a big issue. Even long-time NeXTSTEP aficionados must release that Rhapsody selling at $700 is a non-starter. We might as well fold up our tents now and go home. Rhapsody will never be a mainstream OS if the price remains at the NeXTSTEP levels. Now, we have various assurances from various people at Apple, but no specific numbers. And this is a case where the specific numbers do mean a lot. I don't want to "just trust" that Apple will price things correctly when it comes to making my own decisions. I want to *know* what their pricing will be. Migration tools are another aspect of "cost", of course. People want to know how much it's going to cost them (in time & effort) to develop for Rhapsody. Those of us who are familiar with NeXTSTEP are more likely to be optimistic about this issue, but then we don't have some already-written 500,000 line MacOS program staring at us. > There are a variety of feedback channels that appear to exist, > and at least some Apple people regularly hang out in the newsgroups. > Maybe I'm naive, but perhaps if we (as a developer community) > could clearly articulate what we want, Apple might do a slightly > better job of addressing it. I think people have been doing a fine job of bugging Apple, although perhaps with too many voices such that Apple may wonder what the most critical issue is. Of course, if they did answer "the most critical issue", all they'd get is a new list with a new "most critical issue". My own feeling is that it might be quite reasonable for Apple to remain quiet on details until WWDC, and then try to show the answers to many questions at once. However, Apple better have a fair amount of answers for WWDC (even if some of those answers are " will be ready in July, will not happen until Jan 1988"). Another touchy issue is that they have to be able to deliver on whatever they promise. Note this is a good reason for them to keep quiet until they *know* what they can deliver. This is a pretty dramatic transition here, and developers need to *know* that Apple can deliver on what it says (whatever that might be). --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From gad@eclipse.its.rpi.edu Mon Apr 14 17:47:24 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA02756; Mon, 14 Apr 97 17:47:24 -0700 Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id UAA71980 for ; Mon, 14 Apr 1997 20:47:14 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA26867; Mon, 14 Apr 97 20:47:12 -0400 Message-Id: <9704150047.AA26867@eclipse.its.rpi.edu> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Mon, 14 Apr 97 20:47:10 -0400 To: Multiple recipients of list Subject: Re: Developer communication References: <199704142129.RAA21631@digifix.com> > You can see what Apple will have available in a short few months > NOW with OpenStep 4.2. In three weeks, you can see Rhapsody at > the WWDC, and shortly after that, run it on your PPC. Is release 4.2 actually available yet? I think much of the anxiety in the developer community will remain until they have some version of Rhapsody that they can run on their own PPC hardware. It's too much to ask them to buy some Intel box, or three-year-old NeXT hardware, when they know damn well that they want to develop on their brand new top-of-the-line PowerMac(s) which they already own. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From gad@eclipse.its.rpi.edu Tue Apr 15 15:25:39 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA16800; Tue, 15 Apr 97 15:25:39 -0700 Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id SAA50262; Tue, 15 Apr 1997 18:25:29 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA03461; Tue, 15 Apr 97 18:25:27 -0400 Message-Id: <9704152225.AA03461@eclipse.its.rpi.edu> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Tue, 15 Apr 97 18:25:25 -0400 To: rhapsody-talk@omnigroup.com Subject: Re: File types in Rhapsody Cc: sebestyen_g@usa.net References: <3353C91B.C1E72497@usa.net> Gabriel Sebestyen asked in rhap-dev: > What would be the right way of the identification of the file > types ? Let me ignore the loaded phrase of "right way", and just say that my opinions are: > a., general solution (UNIX/Win/etc.): by filename extension. > b., Macintosh solution: by a four-letter app/subtype integrated > into the file's data fork (Do I know well? :-] ) > c., A third way is, for example, the MIME content types (Well, > Microsoft knows the future when this one is the part of > Win95/NT)? For the immediate-term solution, I'd want either A or B. I'm sure that C would work out brilliantly once someone figures out all the issues, but for now I'd rather stick with something which has been shown to work in a desktop setting. As to choosing between A and B, I'd first like to say that B (as implemented in NeXTSTEP) does work better than most MacOS advocates might initially expect. I had used the MacOS a lot before seeing NeXTSTEP, and when I started using NeXTSTEP I expected this to be a real drawback. After several years of using it (Note: "it" as it is implemented in NeXTSTEP, not any MS-Windows implementation), I'd have to say that it seems to work quite well. However, having said that, it would not bother me to see option A (the MacOS version), used in Rhapsody (although the low-level implementation should be done differently). I expect that mac-users will probably be more comfortable if the file type were not part of the file name (as it is in B), and if there was some sort of "developer ID" in addition to the "file type" information. Note that my "developer ID" field is a slightly different concept from the "creator field" in the MacOS, but it'd be close enough that Mac users would be comfortable with it (many probably wouldn't even notice the difference). It is pretty obvious that Rhapsody will *have* to support creator and type fields on disks formatted for the MacOS, and in a completely compatable way (so users can boot up in either operating system and still access those MacOS-type files). However, any of these other methods are workable, and as developers we should be able to deal with the details of any of these implementations. I consider this an issue which needs to be decided based on user-interface than developer concerns. That's my wish list. It's all speculation, and in some way I don't really care too much which of these Apple goes with for Rhapsody. Instead of listing specific options and saying "Hey let's vote!", we might want to think of the *characteristics* we want, and ask what would best fit those characteristics. So, forget the list above, and come up with a list of characteristics: 1) The method used must in some way to tie a document to an application, in the sense that double-clicking on the document can start up the "right" application. The info about this tie-in is with the document itself. 2) It'd be very very useful if the method used for Rhapsody could also work on other implementations of OpenStep. I guess the OpenStep API's could hide the details, but I don't want to arrange things one way for Rhapsody, and some other way for OpenStep/WindowsNT, and some other way for OpenStep/Solaris. 3) The method should be something which can be implemented fairly quickly, as we can't afford some multi-year delay as we figure out some incrediably amazing and perfect system. I don't even think we can afford a four-month delay. 4) The method used must be workable over a network (where network clients might have access to a directory of files, but they won't have access to other things on the server). [Note that I feel choices A and B both meet this requirement, so don't get *too* excited by what I mean by it. I just don't want someone to propose some new option "D" which did not have this characteristic.] I think those are the important characteristics. I have some other "nice characteristics", which cause me to want something slightly different than the current MacOS or NeXTSTEP implementations for this, but I figure the above should provide enough to talk about for now. I'd be more interested in hearing about what people think the list of *characteristics* should be, and not just some religious war over the three specific proposals originally listed. My guess is that "THE right way" could easily be something which isn't an exact match of any of the options listed. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From erbenson@akcache.com Tue Apr 15 18:54:59 1997 Return-Path: Received: from MAILHOST.AKCACHE.COM by omnigroup.com (NX5.67f2/NX3.0M) id AA18492; Tue, 15 Apr 97 18:54:59 -0700 Received: from [206.66.199.124] by mailhost.akcache.com (Netscape Mail Server v1.1) with SMTP id AAA185 for ; Tue, 15 Apr 1997 17:57:56 -0800 Subject: Re: File types in Rhapsody Date: Tue, 15 Apr 97 17:54:34 -0800 X-Sender: erbenson@mailhost.akcache.com X-Mailer: Claris Emailer 1.1 From: Ethan Benson To: "Multiple recipients of list" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-Id: <19970416015755618.AAA185@[206.66.199.124]> > 1) The method used must in some way to tie a document to an > application, in the sense that double-clicking on the > document can start up the "right" application. The info > about this tie-in is with the document itself. > 2) It'd be very very useful if the method used for Rhapsody > could also work on other implementations of OpenStep. I > guess the OpenStep API's could hide the details, but I don't > want to arrange things one way for Rhapsody, and some other > way for OpenStep/WindowsNT, and some other way for > OpenStep/Solaris. > 3) The method should be something which can be implemented > fairly quickly, as we can't afford some multi-year delay as > we figure out some incrediably amazing and perfect system. > I don't even think we can afford a four-month delay. > 4) The method used must be workable over a network (where > network clients might have access to a directory of files, > but they won't have access to other things on the server). > [Note that I feel choices A and B both meet this requirement, > so don't get *too* excited by what I mean by it. I just > don't want someone to propose some new option "D" which > did not have this characteristic.] > >I think those are the important characteristics. I have some other >"nice characteristics", which cause me to want something slightly >different than the current MacOS or NeXTSTEP implementations for >this, but I figure the above should provide enough to talk about >for now. I'd be more interested in hearing about what people think >the list of *characteristics* should be, and not just some religious >war over the three specific proposals originally listed. My guess >is that "THE right way" could easily be something which isn't an >exact match of any of the options listed. I think the Mac way is closer to the characteristics above then other ways. I like the above characteristics, the characteristics I am looking for is: seperate identifiers for the File type and creator Application. the file name is completly independent of the file type and/or creator. every application having its own set of file types it implicitly supports as to assign the correct Icon for it's files. this would never need to be maintained by the user, (like file extension lists are) this also allows an application's files to have similer icons as the app. -- I believe the Mac way is more complete and much cleaner then other methods, since the creator code allow multiple apps to be able to have there own text files, where with file extensions, any file with the text extension opens simpletext without a specific overide. also it allows each app's files to have there own icons even if they support the same file types as other applications. I believe a method of exporting files to other platforms should be handled in another way other then Lowest Common Denominator, the most common excuse for file extensions. I think that file extensions are ugly and arcane, and I believe that they will be rejected by current Mac users. they can be a cosmetic convenience but nothing more. for networks the server software could maintain a generic file type extension invisibly and transparently (the local file system would not see it and compatible remote file systems would not see it) AppleShare 4.0 does this for short file names for primitive network clients that do not support long file names, however the file system, nor the files itself can see this, because it does not exist, it only shows up on primitive systems, it is stored in privilege files I presume. the next version of OpenStep (assuming it is continued seperate from Rhapsody) should be upgraded to support the same method Rhapsody uses for compatibility. I think that users should be saving there files in the correct platform format when they tranport files since every platform uses a different format anyway and will need to be translated anyway, or the file system could maintain a extension transparently that reflects the File Type as defined in the File Type, and changing it changes nothing about the file nor what app is opened when double clicked. I think it is easier for the system to be backward compatible to the file extension then the Mac system, I mean that if Rhapsody uses the Mac way (or somthing that follows the Mac methods principles) will automaically support current Mac files, and the current OpenStep files wld be supported by PC Exchange, which will use the current list already defined by WorkSpace Inspector, where if File Extensions are used then all the Mac files will be destroyed, and the users willl have to manuely add a arcane file extension to every one of there files. Ethan Benson From sanguish@digifix.com Tue Apr 15 20:25:55 1997 Return-Path: Received: from digifix.digifix.com by omnigroup.com (NX5.67f2/NX3.0M) id AA19196; Tue, 15 Apr 97 20:25:55 -0700 Received: (from sanguish@localhost) by digifix.com (8.8.5/8.8.5) id XAA28007; Tue, 15 Apr 1997 23:26:11 -0400 (EDT) Message-Id: <199704160326.XAA28007@digifix.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.1mach v148) In-Reply-To: <9704152225.AA03461@eclipse.its.rpi.edu> X-Nextstep-Mailer: Mail 4.1mach (Enhance 2.0b5) Received: by NeXT.Mailer (1.148) From: Scott Anguish Date: Tue, 15 Apr 97 23:26:10 -0400 To: gad@eclipse.its.rpi.edu Subject: Re: File types in Rhapsody Cc: Multiple recipients of list Reply-To: sanguish@digifix.com References: <9704152225.AA03461@eclipse.its.rpi.edu> Garance A Drosehn wrote: > Gabriel Sebestyen asked in rhap-dev: > > What would be the right way of the identification of the file > > types ? > > Let me ignore the loaded phrase of "right way", and just say that > my opinions are: > > > a., general solution (UNIX/Win/etc.): by filename extension. > > b., Macintosh solution: by a four-letter app/subtype integrated > > into the file's data fork (Do I know well? :-] ) > > c., A third way is, for example, the MIME content types (Well, > > Microsoft knows the future when this one is the part of > > Win95/NT)? > > For the immediate-term solution, I'd want either A or B. I'm sure > that C would work out brilliantly once someone figures out all the > issues, but for now I'd rather stick with something which has been > shown to work in a desktop setting. > > As to choosing between A and B, I'd first like to say that B (as > implemented in NeXTSTEP) does work better than most MacOS advocates > might initially expect. Uh, I think you mean that A as it is implemented in NEXTSTEP works better than most MacOS advocates might expect..... > I had used the MacOS a lot before seeing > NeXTSTEP, and when I started using NeXTSTEP I expected this to be > a real drawback. After several years of using it (Note: "it" as > it is implemented in NeXTSTEP, not any MS-Windows implementation), > I'd have to say that it seems to work quite well. > > However, having said that, it would not bother me to see option A > (the MacOS version), used in Rhapsody (although the low-level > implementation should be done differently). I expect that mac-users > will probably be more comfortable if the file type were not part > of the file name (as it is in B), and if there was some sort of > "developer ID" in addition to the "file type" information. Note > that my "developer ID" field is a slightly different concept from > the "creator field" in the MacOS, but it'd be close enough that > Mac users would be comfortable with it (many probably wouldn't even > notice the difference). > This could be implemented much in the same way that .dir.tiff is used now.. put .apple_info into a document folder, and that holds the extension and additional creator information. The Workspace/OpenPanel/SavePanel UI could then hide the visible extension on the end of the name. I'll second Garance's note on A... its much easier to use than the Windows implementation of things.. I beleive this is largely due to the inspector allowing you to select from the applications that support opening a certain file type. Even a combination of A and B would work well... allow a Workspace Inspector to put a .preferred_app in a file directory.. double click on that file directory and that app opens. > 1) The method used must in some way to tie a document to an > application, in the sense that double-clicking on the > document can start up the "right" application. The info > about this tie-in is with the document itself. > 2) It'd be very very useful if the method used for Rhapsody > could also work on other implementations of OpenStep. I > guess the OpenStep API's could hide the details, but I don't > want to arrange things one way for Rhapsody, and some other > way for OpenStep/WindowsNT, and some other way for > OpenStep/Solaris. Yes! Very important. Apple has to keep the cross-platform issues in mind in doing this. The current multi-fork situation doesn't work well in cross-platform issues. The world is most definately moving in that direction at a screamingly fast pace. From welles@allele.com Tue Apr 15 20:52:27 1997 Return-Path: Received: from allele.allele.com by omnigroup.com (NX5.67f2/NX3.0M) id AA19352; Tue, 15 Apr 97 20:52:27 -0700 Received: by allele.com (NX5.67f2/NX3.0M) id AA09133; Tue, 15 Apr 97 20:45:55 -0700 Message-Id: <9704160345.AA09133@allele.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Robert Welles Date: Tue, 15 Apr 97 20:45:52 -0700 To: rhapsody-talk@omnigroup.com Subject: Re: Developer communication References: <9704150047.AA26867@eclipse.its.rpi.edu> On Mon, 14 Apr 97 17:50:09 -0700 Garance A Drosehn wrote: I think much of the anxiety in the developer community will remain until they have some version of Rhapsody that they can run on their own PPC hardware. It's too much to ask them to buy some Intel box, or three-year-old NeXT hardware, when they know damn well that they want to develop on their brand new top-of-the-line PowerMac(s) which they already own. Some of us have already made the investment in Intel hardware, paid a bundle for NS/OS development software for it and are worried that we will be forced to buy PPC hardware to develop for Rhapsody. I would like to hear from Apple that whatever ships in June will run on Intel. I would love to buy a PPC machine after I have written off my Intel stuff. Bob --- Robert Y. Welles, (408)867-9567 welles@allele.com MIME ok. From uucp@cubiculum.com Tue Apr 15 22:24:26 1997 Return-Path: Received: from tunix.cubiculum.com by omnigroup.com (NX5.67f2/NX3.0M) id AA20262; Tue, 15 Apr 97 22:24:26 -0700 Received: by cubiculum.com (NX5.67f2/NX3.0M) id AA20736; Wed, 16 Apr 97 01:24:12 -0400 Received: by kannix.cubiculum.com (NX5.67g/NeXT-2.0) id AA24532; Wed, 16 Apr 97 01:21:51 -0400 Message-Id: <9704160521.AA24532@ kannix.cubiculum.com > Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Face: B6DESMpZ'<"P]D0{Aaq$#h/PfN=wI.C{,&<2_;#|.("xO+oeVic@@=zI2zD#NR~S#l*OV}[ In-Reply-To: <9704160345.AA09133@allele.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ronald C.F. Antony Date: Wed, 16 Apr 97 01:21:47 -0400 To: Multiple recipients of list Subject: Re: Developer communication Reply-To: "Ronald C.F. Antony" References: <9704160345.AA09133@allele.com> X-Direct-Marketers: : Add me to your do-not-solicit list >Some of us have already made the investment in Intel hardware, paid a bundle >for NS/OS development software for it and are worried that we will be forced >to buy PPC hardware to develop for Rhapsody. I would like to hear from Apple >that whatever ships in June will run on Intel. I would love to buy a PPC >machine after I have written off my Intel stuff. Guess what, there are even still people that use black hardware and are happy with it. I just got a 166MMX Pentium which by means of all benchmarks (disk, screen, CPU, RAM 80MB) is somewhere between two and 10 times as fast as my black hardware. But in truth, the black hardware was so well engineered, that the difference is hardly noticeable for everyday work. The only times the PC is considerably better is for large compiles or very intensive computation. For all my productivity work, there is hardly a perceptible performance difference. I'm extremely happy with this hardware, it is much more stable than any PC, (uptime measured in months) etc. and I would be quite angry if I had to toss it out (besides, I may not even have the cash to replace all this hardware right away). Given that most everything is already in place for the old hardware (drivers, OS, etc.) it would be a pity if they dropped support. It is amazing to compare the performance of an eight year old PC/Mac to an eight year old NeXT. A true eye opener. (Only requirement: don't memory starve your computers 32-40 MB RAM min.) I really wonder how well the late 040 Macs would do with the Rhapsody OS. From uucp@cubiculum.com Tue Apr 15 22:24:31 1997 Return-Path: Received: from tunix.cubiculum.com by omnigroup.com (NX5.67f2/NX3.0M) id AA20263; Tue, 15 Apr 97 22:24:31 -0700 Received: by cubiculum.com (NX5.67f2/NX3.0M) id AA20729; Wed, 16 Apr 97 01:24:10 -0400 Received: by kannix.cubiculum.com (NX5.67g/NeXT-2.0) id AA24500; Wed, 16 Apr 97 01:08:16 -0400 Message-Id: <9704160508.AA24500@ kannix.cubiculum.com > Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Face: B6DESMpZ'<"P]D0{Aaq$#h/PfN=wI.C{,&<2_;#|.("xO+oeVic@@=zI2zD#NR~S#l*OV}[ In-Reply-To: <19970416015755618.AAA185@[206.66.199.124]> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ronald C.F. Antony Date: Wed, 16 Apr 97 01:08:12 -0400 To: Multiple recipients of list Subject: Re: File types in Rhapsody Reply-To: "Ronald C.F. Antony" References: <19970416015755618.AAA185@[206.66.199.124]> X-Direct-Marketers: : Add me to your do-not-solicit list >the file name is completly independent of the file type and/or creator. [...] >also it allows each app's files to have there own icons even if they >support the same file types as other applications. [...] >I believe a method of exporting files to other platforms should be >handled in another way other then Lowest Common Denominator, the most >common excuse for file extensions. This is typical Mac-speak, and the very reason I never wanted a Mac. The Mac makes it extremely difficult to outsmart your computer, since it assumes the computer is smarter than you. File-types are the central things, not applications. Tools that work on particular file types are secondary. Data should not even know who or what is working on it. (In other words, this is the OO paradigm pushed to files). Files that are aware of their creators encourage to use of standard violating application specific "enhancements", etc. Even worse, try to use a power user's tool like a Unix shell on files without file types... It is very easy to recurseivly traverse a directory tree and have all tiff files compressed, but without file extensions this turns into a major problem. I consider a file extension like a person's last name. Somtimes I have x.dat, x.tiff, x.wk1, x.frame to indicate that x is the topic of the files, but there are several related files (like a spreadsheet calculation, a FrameMaker letter, a tiff graphic, and a raw data file). This allows me to select all the apropriate files with the correct wildcard expression. If there are no file extensions, I have to find unique names for each of these, which makes life a lot more difficult. The worst idea above is to have the same file type with creator specific icons! A tiff file is a tiff file is a tiff file. I don't want no subliminal advertizing for the company which happened to create a particular instance. I want to look at my file browser and instantly be able to spot all files of a given type by their icon, I don't want to learn five different ones! The NeXT way works extremely well: each file type has a unique extension, which you can register with NeXT. each application has a way to register all file types it can work on when you select a file in the WorkspaceManager/Finder you can see which Apps can open a file, and you can decide on a one-time basis which application should open the file, and you can set the default application that will open it in the future. When you save files, you don't have to type the extension (which is error prone), but the application appends the file extenions automatically, unless you added it yourself. This ensures that files always have the correct extension. So far I have yet to encounter a scenario where this does not work. One should after all not forget, that while a GUI is a nice way to interact with a computer for a computer illiterate person, power users ofen use a command line interface and scripts, because they are a lot faster, can be batched and scheduled, etc. In these circumstances it is imperative to be able to make decisions based on the actual name of the file. What NeXT could do, is to filter the file extensions from display unless the Unix Expert setting is active, similar to the way Win95 lets you hide file extensions, while in fact they are always there... Greetings, Ronald From uucp@cubiculum.com Wed Apr 16 00:17:18 1997 Return-Path: Received: from tunix.cubiculum.com by omnigroup.com (NX5.67f2/NX3.0M) id AA21093; Wed, 16 Apr 97 00:17:18 -0700 Received: by cubiculum.com (NX5.67f2/NX3.0M) id AA22439; Wed, 16 Apr 97 03:16:57 -0400 Received: by kannix.cubiculum.com (NX5.67g/NeXT-2.0) id AA24797; Wed, 16 Apr 97 03:15:24 -0400 Message-Id: <9704160715.AA24797@ kannix.cubiculum.com > Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Face: B6DESMpZ'<"P]D0{Aaq$#h/PfN=wI.C{,&<2_;#|.("xO+oeVic@@=zI2zD#NR~S#l*OV}[ In-Reply-To: <19970416055807551.AAA176@[206.66.199.124]> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ronald C.F. Antony Date: Wed, 16 Apr 97 03:15:19 -0400 To: Ethan Benson Subject: Re: File types in Rhapsody Cc: Multiple recipients of list Reply-To: "Ronald C.F. Antony" References: <19970416055807551.AAA176@[206.66.199.124]> X-Direct-Marketers: : Add me to your do-not-solicit list >This is typical UNIX speak... the user should be a expert user or else >they have no buisness using a computer. No, but users should not be punished for wanting to do more. The Mac ties you down once you have grown wings on a computer. The point is, that I have yet to find anyone who thinks the NeXT was difficult to use. The extensions are handled in a very graceful way: When you create a file, they are automatically appended, if you use the Open panel within an application, the application filters files to show only the files that are applicable, and the Browser/Finder/Workspace shows the extensions, but they are hardly disturbing, icons match the extension, and hence different types of files are easy to spot. What's wrong with this? Nothing. What's great about it? It lets standard UNIX shell scrips work on the files. >>This allows me to select all the >>appropriate files with the correct wildcard expression. If there are no file >>extensions, I have to find unique names for each of these, which makes life >>a lot more difficult. > >No it does not you can search by file type in teh Find File application That's the point. An application (at least in NeXTSTEP/OpenStep speak) is a GUI tool, but that does not mesh with scripts. If you think about the /bin/file CLI-tool, then it is severely limited. Also e.g. to LZW compress all tiff files I can now do this in a shell window: foreach i ( *.tiff ) mv $i tmp.tiff tiffutil -lzw tmp.tiff -out $i rm tmp.tiff end And there it goes. If I had to check the file type by means of some additional tool this script would get considerably more complicated, error prone and difficult to write, i.e. it would require MORE expertise, rather than LESS. So the computer for "the rest of us" would WIDEN the gap between the "experts" and the "novice" rather than narrowing down. Even worse, any type of really useful file-type check application other than the defunct /bin/file would be Apple/NeXT proprietary, and defeat the purpose of shell scripts, i.e. that they are mostly platform independent and can run as well on a $500'000 multi-CPU SGI corporate UNIX server as on your own desktop. >>The worst idea above is to have the same file type with creator specific >>icons! A tiff file is a tiff file is a tiff file. I don't want no subliminal >>advertising for the company which happened to create a particular instance. >>I want to look at my file browser and instantly be able to spot all files of >>a given type by their icon, I don't want to learn five different ones! >> >I think this is absurd, I want to be able to tell what app is going to >open by the Icon, you arcane way does not allow this. You know this by a) looking at the inspector, b) by setting the default app that you want to open documents of a particular type. Personally, if I work with tiff files, I have my favorite bitmap image editing program. I don't want to see a different icon, just because someone else created that file with a different app, which for all intents and purposes I may not even own. Besides, without file extensions and with creation specific icons it would be a REAL pain to figure out what type of file you are dealing with. Usually one works on one type of file with one application, unless one invokes a non-standard app for some features it has over the standard app. That's the way the NeXT scheme works. It opens things in the standard application, which can either be determined by the system, or overridden on a per user basis. If for some reason that file should be opened with another app, it can be done on a one shot basis. >>The NeXT way works extremely well: >yes but the Mac way works even better. How long did you work on a NeXT? I worked for a few years with Macs until I got sick of it. Since then whenever I tried a Mac, or even worse, Win, I was more than happy to get back to my environment. (And yes, I have been using NeXT software since about 1989...) >> and you can decide on a one-time basis which application >>should open the file, and you can set the default application that will >>open it in the future. > >On the Mac this step is unneccessary Because you are forced into using a particular app. I want to be able to override which app opens my files, and NeXT lets me do this. I don't have to register my files for apps that open them on the NeXT, that is done automatically, but I CAN do it, if I want to make the computer deviate from the default behavior. e.g. I can make EPS files display in the PostScript previewer Preview.app which usually takes EPS files (.eps), or I can have them opened by YAP.app, Illustrator, etc. I can change the behavior permanently or on a one time basis. >>What NeXT could do, is to filter the file extensions from display unless the >>Unix Expert setting is active, similar to the way Win95 lets you hide file >>extensions, while in fact they are always there... > >this is a very lousy hack, I have used wincrap 95 and this is the >lousiest way I have ever seen, it is just a crappy way to hide a arcane >bug in the system... File extensions File extensions are not any more a bug than directories, etc. They are a notational convention to structure data, the same as a "/" is a notational convention to separate paths in a hierarchical data structure call directory tree. File extensions are an orthogonal structure to directories, hence they use a different notation. There is nothing wrong with this. Other attributes, since they are rarely used as a basis for file selection are handled in a different way, such as creation date, file permissions, etc. As a matter of fact, one feature that I MISS in Unix, that you would probably hate, and that is great about DEC's VMS is that not only does it append a file extension, but also a version number, so you'd have [path.to.directory]fileName.extension;version as a complete file name. You can set in the environment how many old versions of a file are kept. Each time you save a file, the version number is incremented, so it's easy to go back to previous edits. This scheme beats the scheme by Macs, PCs or Unix where there is either a .backup or filename~ that is sometimes kept, if the application decides to let you do this. VMS handles this at the system level, and does not need a cooperative application. Of course you can argue that the whole idea of hierarchical, structured file storage is bad, and hence all data should be stored in a free-form database and accessed by means of queries on attributes like creation time, creation date, permissions, UID, application, file type, version, keywords, etc. which at some point may or may not happen. But as long as we are dealing with hierarchical directory trees, extensions are essential. From gad@eclipse.its.rpi.edu Wed Apr 16 00:40:23 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA21241; Wed, 16 Apr 97 00:40:23 -0700 Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id DAA118094 for ; Wed, 16 Apr 1997 03:40:22 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA04519; Wed, 16 Apr 97 03:40:20 -0400 Message-Id: <9704160740.AA04519@eclipse.its.rpi.edu> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Wed, 16 Apr 97 03:40:17 -0400 To: Multiple recipients of list Subject: Re: File types in Rhapsody References: <19970416015755618.AAA185@[206.66.199.124]> Ethan Benson writes: > Garance writes: > > [the initial list of four characteristics] > > > > I think those are the important characteristics. I have some > > other "nice characteristics", which cause me to want something > > slightly different than the current MacOS or NeXTSTEP > > implementations for this, but I figure the above should provide > > enough to talk about for now. I'd be more interested in hearing > > about what people think the list of *characteristics* should > > be, and not just some religious war over the three specific > > proposals originally listed. My guess is that "THE right way" > > could easily be something which isn't an exact match of any of > > the options listed. > > I think the Mac way is closer to the characteristics above then > other ways. This immediately misses the point what I was asking for. I was hoping for a list of useful characteristics, not a vote of "I think method is the one we should use". In particular, if you are going to vote for the *exact* implementation which is currently on the MacOS, then that implementation directly contradicts characteristic #2. That is to say, Rhapsody will end up using some method for document->app mapping which can not happen on WindowsNT or Solaris. That makes it harder for OpenStep developers to port to multiple platforms. Now, something functionally equivalent to the MacOS ideas might not contradict with characteristic #2, however you jumped right in and voted for an exact implementation -- even while claiming you were talking about the list of characteristics. > I like the above characteristics, the characteristics I am looking > for is: > > 5) seperate identifiers for the File type and creator Application. > > 6) the file name is completely independent of the file type and/or > creator. I can see these characteristics would be useful, particularly for people coming from the Mac environment. I personally do not think there needs to be a "creator id" (exactly as it is implemented in the MacOS), but I can see that it'd be useful to have some kind of "application selector" field in addition to the "file type" field. > 7) every application having its own set of file types it implicitly > supports as to assign the correct Icon for it's files. this > would never need to be maintained by the user, (like file > extension lists are) The way this is phrased, it sounds like "I know the method I want to pick, so let me describe it to you with characteristics which are not true for the method I do not like". This misses the point. You *assume* you know what "file extension lists" would be like. Do not describe characteristics by saying "method does not have this characteristic". Just describe what the characteristic itself means. If I understand what you mean by this characteristic (and I may not understand it), it is certainly possible for a file-extension setup to support this. If you are thinking of how MS-Windows does their mapping, then I understand what you mean by this characteristic, however I'd also say that other implementations of file-extensions does not have the mapping-problem that you are talking about. If you're talking about the NeXTSTEP implementation (as one other example), then I don't even understand what you are referring to. Again, you may be letting one particular implementation determine what you assume for all possible implementations. I think that assumption will confuse the issue. Note that I'm not arguing *for* file-name extensions when I say that. All I'm saying is "don't vote for some specific method, but instead let's talk about the list of characteristics". --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From gad@eclipse.its.rpi.edu Wed Apr 16 00:43:19 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA21316; Wed, 16 Apr 97 00:43:19 -0700 Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id DAA118198 for ; Wed, 16 Apr 1997 03:43:18 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA04528; Wed, 16 Apr 97 03:43:16 -0400 Message-Id: <9704160743.AA04528@eclipse.its.rpi.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Wed, 16 Apr 97 03:43:14 -0400 To: Multiple recipients of list Subject: Re: File types in Rhapsody References: <9704152225.AA03461@eclipse.its.rpi.edu> <199704160326.XAA28007@digifix.com> Scott Anguish writes: Garance A Drosehn wrote: > > As to choosing between A and B, I'd first like to say that B > > (as implemented in NeXTSTEP) does work better than most MacOS > > advocates might initially expect. > > Uh, I think you mean that A as it is implemented in NEXTSTEP > works better than most MacOS advocates might expect..... Er, uh, yeah. Sorry about that! I think that my previous reply (to a different person) also added to the list by talking about methods 1-4, instead of A-D, and went on to assign numbers to 5-7! Maybe I shouldn't stay up so late playing WarCraft II... --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From gad@eclipse.its.rpi.edu Wed Apr 16 00:50:59 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA21400; Wed, 16 Apr 97 00:50:59 -0700 Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id DAA101116 for ; Wed, 16 Apr 1997 03:50:57 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA04549; Wed, 16 Apr 97 03:50:55 -0400 Message-Id: <9704160750.AA04549@eclipse.its.rpi.edu> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Wed, 16 Apr 97 03:50:53 -0400 To: Multiple recipients of list Subject: Re: Developer communication References: <9704160345.AA09133@allele.com> Robert Welles writes: > On Mon, 14 Apr 97 17:50:09 -0700 Garance A Drosehn > wrote: > > I think much of the anxiety in the developer community will > remain until they have some version of Rhapsody that they > can run on their own PPC hardware. It's too much to ask them > to buy some Intel box, or three-year-old NeXT hardware, when > they know damn well that they want to develop on their brand > new top-of-the-line PowerMac(s) which they already own. > > Some of us have already made the investment in Intel hardware, > paid a bundle for NS/OS development software for it and are > worried that we will be forced to buy PPC hardware to develop > for Rhapsody. I would like to hear from Apple that whatever ships > in June will run on Intel. I would love to buy a PPC machine > after I have written off my Intel stuff. Before we go down this path, please note that what I said does not contradict what Robert is saying. Let's get out of this "NeXTSTEP developers vs MacOS developers" mode, if at all possible. The fact that I understand the issue for Mac developers does not mean that I want Apple to kill off NeXTSTEP/Intel. (I don't know that Robert misunderstood my point, it's just after reading this I wanted to make sure everyone realizes that I do not disagree with Robert's point -- even though I stand completely behind what I said and exactly as I said it). Note that it's my assumption that anything done for the "Yellow Box" of Rhapsody will also show up in NeXTSTEP/Intel. I may be wrong in that assumption, but it is based on many comments which have come in interviews with various Apple employees. Both of the following are true, in my opinion: 1) People who just bought nice PowerPC boxes should not be told that they must buy Intel hardware right now in order to start programming for Rhapsody on PPC. 2) People who just bought nice Intel-based hardware to run NeXTSTEP/Intel should not be forced into buying PPC hardware just to develop for the "yellow box" of Rhapsody. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From gad@eclipse.its.rpi.edu Wed Apr 16 01:08:32 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA21643; Wed, 16 Apr 97 01:08:32 -0700 Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id EAA49194 for ; Wed, 16 Apr 1997 04:08:30 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA04605; Wed, 16 Apr 97 04:08:29 -0400 Message-Id: <9704160808.AA04605@eclipse.its.rpi.edu> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Wed, 16 Apr 97 04:08:27 -0400 To: Multiple recipients of list Subject: Rhapsody on other hardware (tangent to "Developer communication") References: <9704160521.AA24532@ kannix.cubiculum.com > > > Some of us have already made the investment in Intel hardware, > > paid a bundle for NS/OS development software for it and are > > worried that we will be forced to buy PPC hardware to develop > > for Rhapsody. I would like to hear from Apple that whatever > > ships in June will run on Intel. I would love to buy a PPC > > machine after I have written off my Intel stuff. > > Guess what, there are even still people that use black hardware > and are happy with it. I just got a 166MMX Pentium which by means > of all benchmarks (disk, screen, CPU, RAM 80MB) is somewhere > between two and 10 times as fast as my black hardware. But in > truth, the black hardware was so well engineered, that the > difference is hardly noticeable for everyday work. My own opinion is that NeXT hardware is old enough that owners of it really should start writing it off. I understand the attraction, as I own three NeXTstations, but it really really is too old to compete with today's hardware (either Intel or PPC). Yes I love it, yes it was built very well, but the newest box you can buy was built more than four years ago. Rhapsody will be "real" (released to users) sometime next year, which will make the *newest* NeXT five years old at the *start* of Rhapsody. It is time to write that hardware off. I'm not sure why your Pentium system does not compare favorably to your NeXT hardware, but it's certainly possible to build Intel-based hardware which will out-perform NeXT hardware, in just about any way you wish to measure performance. While various people at Apple have made reassuring comments about NeXTSTEP/Intel, nothing much has been said about NeXTSTEP on old NeXT hardware. NeXTSTEP on HP hardware is already gone, NeXTSTEP on SPARC hardware is nearly useless (because it isn't available for most of the hardware Sun actually makes today), and I have trouble believing that NeXTSTEP on NeXT hardware is going to see all that much more work in upgrades. This is just my opinion, don't scream at Apple about it. > I'm extremely happy with this [NeXT] hardware, it is much more > stable than any PC, (uptime measured in months) etc. and I would > be quite angry if I had to toss it out (besides, I may not even > have the cash to replace all this hardware right away). NeXTSTEP/Intel on my 60 MHz pentium box is pretty much as reliable as NeXTSTEP/m68k. It doesn't have the 170+ uptimes that my color NeXTstation has, but that's mainly because I'm connecting and disconnecting devices to it much more often. Even then, it regularly goes for a month or two before I decide to reboot it for some reason. It also has more room for RAM, and more room for internal hard disks, and more room for a new ethernet card which supports 100baseT. It could also support multiple monitors, and as it is it already suuports 32-bit color. It will have a lot more upgrade options than my NeXT, and here I'm describing a PC I bought three *years* ago! (a very expensive PC at the time, but still, it is three years old... I'm almost ready to write off this PC, never mind my three NeXTstations!) --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From gad@eclipse.its.rpi.edu Wed Apr 16 01:28:18 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA21802; Wed, 16 Apr 97 01:28:18 -0700 Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id EAA72130 for ; Wed, 16 Apr 1997 04:28:17 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA04651; Wed, 16 Apr 97 04:28:15 -0400 Message-Id: <9704160828.AA04651@eclipse.its.rpi.edu> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Wed, 16 Apr 97 04:28:14 -0400 To: Multiple recipients of list Subject: Re: File types in Rhapsody References: <9704160508.AA24500@ kannix.cubiculum.com > Ronald C.F. Antony writes: > File-types are the central things, not applications. Tools that > work on particular file types are secondary. Data should not even > know who or what is working on it. (In other words, this is the > OO paradigm pushed to files). Files that are aware of their > creators encourage to use of standard violating application > specific "enhancements", etc. I think that this worked particularly well with NeXTSTEP because we had relatively few developers writing programs for relatively few file types. I do expect that having *just* a file type will be more of a problem in the Mac and WindowsNT worlds. > Even worse, try to use a power user's tool like a Unix shell on > files without file types... It is very easy to recurseivly traverse > a directory tree and have all tiff files compressed, but without > file extensions this turns into a major problem. I think this is an irrelevent argument. Similar tools could be devised for other implementations. Or let me rephrase that into a "characteristic" for the list: The method used for implemeting document->app mapping should make it easy to do "power-user" things at a command shell, although the command-shell should not be considered more important than doing what makes sense for a GUI interface. It is important, but not more important. I have avoided assigning a number or a letter to this characteristic, because I'd probably use a roman numeral by mistake... > The worst idea above is to have the same file type with creator > specific icons! A tiff file is a tiff file is a tiff file. I > don't want no subliminal advertizing for the company which happened > to create a particular instance. I want to look at my file > browser and instantly be able to spot all files of a given type > by their icon, I don't want to learn five different ones! I agree with the comment that a "tiff file is a tiff file", but there are namespace-advantages to having a creator field too. On the Mac, for instance, most files of type "TEXT" are really files of very *different* types from each another. They are not "TEXT" is "TEXT" is "TEXT". They should not be treated as such. It does make life easier for naming types if the millions of little shareware applications do not have to dream up some special catchy-looking file type for an application that may be abandoned before the year is over. > The NeXT way works extremely well: ... given the relatively few number of distinctive file types which are created by developers under NeXTSTEP. > So far I have yet to encounter a scenario where this does not work. It is easy to imagine scenerios where it will not work out as well, and I *like* the way NeXTSTEP works. > One should after all not forget, that while a GUI is a nice way > to interact with a computer for a computer illiterate person, > power users ofen use a command line interface and scripts, because > they are a lot faster, can be batched and scheduled, etc. In > these circumstances it is imperative to be able to make decisions > based on the actual name of the file. I do not think that the command-line interface is quite as important as you make it out here. And don't give me lectures about how useful it is, I've been working on systems with command-line interfaces (and command macro languages to manipulate files) for twenty years now. The first priority, in my opinion, is to have a user-friendly GUI interface. If you disagree with that, then we just happen to have different opinions. It is not because I'm too ignorant to know what you are talking about, it's because we have different opinions. I do agree that it's important to allow for manipulating things via a command-line, as that is very useful. However, I think Apple should first worry about how things work at the GUI level, and then figure out how to implement it so the command-line interface is also quite useful. I think it's a mistake to start at the command line, and then say "what GUI can we paste on top of this for people who don't like command lines?". > What NeXT could do, is to filter the file extensions from display > unless the Unix Expert setting is active, similar to the way > Win95 lets you hide file extensions, while in fact they are always > there... I'm not quite sure I like this idea, but perhaps it would work out fairly well. I would like to have both "app-info" and "type-info" as separate fields, but perhaps that could be done in the filename using this method you suggest. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From uucp@cubiculum.com Wed Apr 16 02:16:25 1997 Return-Path: Received: from tunix.cubiculum.com by omnigroup.com (NX5.67f2/NX3.0M) id AA22158; Wed, 16 Apr 97 02:16:25 -0700 Received: by cubiculum.com (NX5.67f2/NX3.0M) id AA24583; Wed, 16 Apr 97 05:15:51 -0400 Received: by kannix.cubiculum.com (NX5.67g/NeXT-2.0) id AA25076; Wed, 16 Apr 97 05:14:41 -0400 Message-Id: <9704160914.AA25076@ kannix.cubiculum.com > Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Face: B6DESMpZ'<"P]D0{Aaq$#h/PfN=wI.C{,&<2_;#|.("xO+oeVic@@=zI2zD#NR~S#l*OV}[ In-Reply-To: <9704160828.AA04651@eclipse.its.rpi.edu> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ronald C.F. Antony Date: Wed, 16 Apr 97 05:14:38 -0400 To: gad@eclipse.its.rpi.edu Subject: Re: File types in Rhapsody Cc: Multiple recipients of list Reply-To: "Ronald C.F. Antony" References: <9704160828.AA04651@eclipse.its.rpi.edu> X-Direct-Marketers: : Add me to your do-not-solicit list >I agree with the comment that a "tiff file is a tiff file", but >there are namespace-advantages to having a creator field too. On >the Mac, for instance, most files of type "TEXT" are really files >of very *different* types from each another. They are not "TEXT" >is "TEXT" is "TEXT". They should not be treated as such. Then that is a design/programmer's mistake. Every file type, (extension or not) should be clearly defined. There should be no generic "text" type, other than say plain ASCII or UniCode files. Every other "text" file should be of type "Microsoft Word File Format Text" or "WordPerfect File Format Text" or "HTML Text". Note that this is NOT the same as a creator ID, since nothing should stop WordPerfect from creating a "Microsoft Word File Format Text" file. Now of course, if Mac apps are so braindead as to use a generic "text" type, and then a creator ID to figure out the subtype, then I see the confusion we have here. The type should correspond to a file format spec, the creator, if such is even stored (which I think is superfluous), should be the creator, completely independent from the format spec in question. Icons should be associated with the format spec, not with the creator, which should be an arbitrary tool that happens to understand a particular file format spec and can work on it. >It does make life easier for naming types if the millions of little >shareware applications do not have to dream up some special >catchy-looking file type for an application that may be abandoned >before the year is over. That is one reason why NeXT/Apple should come up with a universal document framework, whereby all OpenStep apps have an easy API to write/read universal OpenStep files. What I mean here is something along the lines of the Property Lists: a structure that can be read by all OpenStep apps, by virtue of being an OpenStep app, containing the complete structured content of the file. With the appropriate tagging mechanism like in XML or SGML, there could be truely universal documents. Part of such a spec could be user defineable properties, such as default app, etc. Workspace, by virtue of being an OpenStep app, could hence parse these tags before launching the app that opens the file, and decide at that time, what app to launch. These documents then can of course also be compound documents where each app just works on a sub-part thereof. e.g. opening the doc in a spreadsheet would let me edit the data, change the formulas, etc. opening the same file in the text editor would show me a report containing the data, etc. But that's future music. Until then, we need a way to deal with the old each-developer-brews-his-own-format mess, and file extensions seem a good way to handle it >> The NeXT way works extremely well > >... given the relatively few number of distinctive file types >which are created by developers under NeXTSTEP. > >> So far I have yet to encounter a scenario where this does not work. > >It is easy to imagine scenerios where it will not work out as well, >and I *like* the way NeXTSTEP works. Given the way that NeXT always emphasized working on standard file types for data that needs to be exchanged between applications. For data that is application specific, a unique extension works equally well as a unique creator id. In either case, duplicates create problems. >I do not think that the command-line interface is quite as important >as you make it out here. [...] The first priority, in my opinion, is >to have a user-friendly GUI interface. If you disagree with that, >then we just happen to have different opinions. I guess we do have different opinions. I think neither of the two is more important, they are of equal importance. To compare it with a political issue: is it more important to make special schools for the extremely gifted or for the mentally retarded? Neither! Both are a minority, and both should have the same chance of developing their full potential. Common practice is to "fend for the weak" and let the gifted struggle on their own. It is often forgotten that it is as cruel and frustrating for a gifted person to be cut short of their potential, as it is for a mentally challenged. To get back to computers, it is as frustrating for a novice not to be able to copy a file easily, as it is frustrating for a power users to have to drag around files for half an hour, if the same could be acomplished by a shell script in 30 seconds. Both have a worthy cause, and neither should have to suffer in order to make life easier for the other. Even more to the point is, the more computer users have grown up with the devices, and got used to them, the higher the percentage of power users compared to novice users will be, hence investing in power user comfort is investing into the future. Greetings, Ronald From uucp@cubiculum.com Wed Apr 16 02:16:23 1997 Return-Path: Received: from tunix.cubiculum.com by omnigroup.com (NX5.67f2/NX3.0M) id AA22157; Wed, 16 Apr 97 02:16:23 -0700 Received: by cubiculum.com (NX5.67f2/NX3.0M) id AA24576; Wed, 16 Apr 97 05:15:49 -0400 Received: by kannix.cubiculum.com (NX5.67g/NeXT-2.0) id AA25005; Wed, 16 Apr 97 04:42:03 -0400 Message-Id: <9704160842.AA25005@ kannix.cubiculum.com > Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Face: B6DESMpZ'<"P]D0{Aaq$#h/PfN=wI.C{,&<2_;#|.("xO+oeVic@@=zI2zD#NR~S#l*OV}[ In-Reply-To: <9704160808.AA04605@eclipse.its.rpi.edu> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ronald C.F. Antony Date: Wed, 16 Apr 97 04:42:00 -0400 To: gad@eclipse.its.rpi.edu Subject: Re: Rhapsody on other hardware (tangent to "Developer communication") Cc: Multiple recipients of list Reply-To: "Ronald C.F. Antony" References: <9704160808.AA04605@eclipse.its.rpi.edu> X-Direct-Marketers: : Add me to your do-not-solicit list >I'm not sure why your Pentium system does not compare favorably to >your NeXT hardware, but it's certainly possible to build Intel-based >hardware which will out-perform NeXT hardware, in just about any >way you wish to measure performance. You didn't get my point: the Pentium DOES outperform the NeXT by factors ranging from two to ten. However, that does not translate into user experience, since my NeXT hardware is way fast enough for all sorts of productivity work. We have made BELIEVE by bloat-ware of the MS kind, that we cannot live without our computers becoming faster by a factor of two every year. FACT IS that wordprocessing, spreadsheets, e-mail, code editing, web browsing only can eat up so much CPU horse power, while the rest of it's time the CPU spends twiddling its immaginary thumbs. So what I'm saying is that unless I run a large scientific computation for my PhD research, or I compile a significant source tree, the speed difference AS EXPERIENCED BY THE USER, is insignificant. ABSOLUTELY speaking, in terms of benchmarks, the speed difference is significant. It is time, particularly in view of all the castrated NetworkComputer initiatives, to think about how useful the assumption is that we need to toss out our computers every few years. They work fine, they have no rust (hey, it's no car after all), they are fast enough for all reasonable productivity apps, they weren't cheap. So why should I or anyone else be forced to "write them off"? It may be useful for your tax return, but that does not mean the computer stops being useful. It only stops being useful as soon as a manufacturer forcefully pulls the plug, and I can't buy applications, etc. for it anymore, since the tools, OS, etc. does no longer support the hardware. In my book that amounts to extortion to buy new hardware. It is cheaper to have a client run on a decent "old" computer, and run the compute intensive stuff on a compute server, than to constantly replace all the client computers. That's what NCs are about, and that's what "multi-tierd mission critical custom client/server apps" as touted by NeXT not that long ago, are all about. An "old" NeXT is more than adequate to run any sort of thin-clients and/or productivity applications. Now if we had some insane, artificial intelligence, StarTrek like quantum leap in computing, that requires faster machines, that's another issue. But wasting money for what, photorealistically, real-time 3D rendered animated application icons, just to help computer manufacturers push new hardware, that's where my understanding for new hardware purchases ends. The industry has to come to realize that computers ultimately are investment goods like any other. And just because in the past the advances required upgrades at a fast pace, that does not mean that for most purposes, like standard productivity apps, we didn't reach a point where we can expect longer product life cycles. Computer manufacturers have to see that they have no right to require us to buy new hardware at such a pace. >While various people at Apple have made reassuring comments about >NeXTSTEP/Intel, nothing much has been said about NeXTSTEP on old >NeXT hardware. NeXTSTEP on HP hardware is already gone, NeXTSTEP >on SPARC hardware is nearly useless (because it isn't available >for most of the hardware Sun actually makes today), and I have >trouble believing that NeXTSTEP on NeXT hardware is going to see >all that much more work in upgrades. This is just my opinion, >don't scream at Apple about it. Exactly that constitutes a reason to scream at Apple. If a company makes a perfectly workable solution unworkable by stopping to support it, then that warrants screaming. This is like cars requiring air filters or other parts every once in a while, and a car company deciding that after five years they will no longer sell you the parts, because now they have new models out with new features, and that hence they feel you should write off your old car and get a new one. Besides, that what trickle down is supposed to do: for a secretary e.g. an "old" NeXT is just fine. It just doesn't take a 200MHz PPC or Pentium(Pro) to run a text editor to write business correspondence, or to look up a few parts on a database. Resonable hardware purchase policies, replace at the high end, and trickle old stuff down the chain, but to do that, you need software support and compatibility. Greetings, Ronald From stevec@magna.com.au Wed Apr 16 03:35:50 1997 Return-Path: Received: from mail.magna.com.au by omnigroup.com (NX5.67f2/NX3.0M) id AA22645; Wed, 16 Apr 97 03:35:50 -0700 Received: from stevec.magna.com.au (stevec.magna.com.au [203.111.0.146]) by magna.com.au (8.8.5/8.6.10) with SMTP id UAA07954; Wed, 16 Apr 1997 20:35:18 +1000 (EST) Date: 16 Apr 97 20:21:37 +1000 Subject: Re: Developer communication From: "Stephen Coy" To: welles@allele.com, "Multiple recipients of list" X-Mailer: Cyberdog/2.0 Mime-Version: 1.0 Message-Id: X-Fontfamily: Courier X-Fontsize: 10 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, 16 Apr 1997 2:47 PM, ? wrote: >Some of us have already made the investment in Intel hardware, paid a bundle >for NS/OS development software for it and are worried that we will be forced >to buy PPC hardware to develop for Rhapsody. I would like to hear from Apple >that whatever ships in June will run on Intel. I would love to buy a PPC >machine after I have written off my Intel stuff. > G=B9Day, I suspect that Rhapsody developers such as yourself are also very much in the minority. Given the somewhat arbitrary manner in which Apple dropped their OpenDoc developers altogether, I don't like your chances. This is not to say that you won=B9t see Rhapsody on Intel at all, I just think it will be later rather than sooner. Regards, Steve Coy Resolve Software Pty Ltd 4 Andove St Belrose NSW 2085 Australia ****** This message was sent by CyberDog 2.0 ******** From scott_hankin@avid.com Wed Apr 16 07:59:31 1997 Return-Path: Received: from newavid.avid.com by omnigroup.com (NX5.67f2/NX3.0M) id AA24809; Wed, 16 Apr 97 07:59:31 -0700 Received: from [152.165.154.134] by mail.avid.com (SMI-8.6/SMI-SVR4) id KAA27861; Wed, 16 Apr 1997 10:58:27 -0400 X-Sender: shankin@mail.avid.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Apr 1997 10:59:24 -0400 To: rhapsody-talk@omnigroup.com From: Scott Hankin Subject: Re: File types in Rhapsody >That's the point. An application (at least in NeXTSTEP/OpenStep speak) is >a GUI tool, but that does not mesh with scripts. If you think about the >/bin/file CLI-tool, then it is severely limited. Also e.g. to LZW compress >all tiff files I can now do this in a shell window: > >foreach i ( *.tiff ) > mv $i tmp.tiff > tiffutil -lzw tmp.tiff -out $i > rm tmp.tiff >end >And there it goes. If I had to check the file type by means of some additional >tool this script would get considerably more complicated, error prone and >difficult to write, i.e. it would require MORE expertise, rather than LESS. >So the computer for "the rest of us" would WIDEN the gap between the "experts" >and the "novice" rather than narrowing down. foreach i (filetype tiff *) mv $i tmp tiffutil -lzw tmp -out $i rm tmp end Where's the greater complication? Without question if file types were an integral part of the system, some utility would return it for an arbitrary list of files, or (as implied above) return a list of files whose file type matches the one desired. Indeed, I'd expect that utility to be built into the scripting language. Moreover, I'd expect the scripting language that is designed for Rhapsody to contain many additional language extensions, both for GUI manipulation and for the many other things required of a modern OS. The alternate problem also exists. I can name a file anything I want, even foo.tiff, irrespective of file type. Doubtless the tiffutil would fail in this case, even possibly to the extent of zeroing out my file! (I have no immediate knowledge of what tiffutil will do when the input is invalid.) You demonstrate considerable expertise when you run tiffutil on any file whose last four letters happen to be tiff, perhaps more than should be expected of the non-expert user. >Even worse, any type of really useful file-type check application other >than the defunct /bin/file would be Apple/NeXT proprietary, and defeat the >purpose of shell scripts, i.e. that they are mostly platform independent and >can run as well on a $500'000 multi-CPU SGI corporate UNIX server as on your >own desktop. It is unclear that the above is a stated goal of Rhapsody. It is unclear that shell scripts written to run on Rhapsody should be limited to the subset of activities required for them to run on a generic Unix system. >How long did you work on a NeXT? I worked for a few years with Macs until >I got sick of it. Since then whenever I tried a Mac, or even worse, Win, I >was more than happy to get back to my environment. (And yes, I have been >using NeXT software since about 1989...) I hear similar comments from people using vanilla Unix. People have different needs and preferences. I fail to see how this supports your argument. >File extensions are not any more a bug than directories, etc. They are >a notational convention to structure data, the same as a "/" is a notational >convention to separate paths in a hierarchical data structure call directory >tree. File extensions are an orthogonal structure to directories, hence they >use a different notation. There is nothing wrong with this. Other attributes, >since they are rarely used as a basis for file selection are handled in a >different way, such as creation date, file permissions, etc. >As a matter of fact, one feature that I MISS in Unix, that you would probably >hate, and that is great about DEC's VMS is that not only does it append a >file extension, but also a version number, so you'd have File extentions is nothing less than exposing metadata to the user in a space he should have complete control over, i.e., the file's name. It is a holdover from the days when OS designers couldn't figure out a better way of doing things. The MacOS has demonstrated one way that is better. I acknowledge it is not the only possible way, but it is considerably better that the alternatives I've heard stated to date. - Scott ----------------------------- Scott Hankin (scott_hankin@avid.com) In the beginning, there was nothing, then God said, "Let there be light." And there was light. There was still nothing, but you could see it a lot better. From gad@eclipse.its.rpi.edu Wed Apr 16 10:07:33 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA26145; Wed, 16 Apr 97 10:07:33 -0700 Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id NAA87158 for ; Wed, 16 Apr 1997 13:07:22 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA06023; Wed, 16 Apr 97 13:07:18 -0400 Message-Id: <9704161707.AA06023@eclipse.its.rpi.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Wed, 16 Apr 97 13:07:17 -0400 To: Multiple recipients of list Subject: Re: File types in Rhapsody References: <9704160828.AA04651@eclipse.its.rpi.edu> <9704160914.AA25076@ kannix.cubiculum.com > > > I agree with the comment that a "tiff file is a tiff file", > > but there are namespace-advantages to having a creator field > > too. On the Mac, for instance, most files of type "TEXT" are > > really files of very *different* types from each another. They > > are not "TEXT" is "TEXT" is "TEXT". They should not be treated > > as such. > > Then that is a design/programmer's mistake. Every file type, > (extension or not) should be clearly defined. There should be no > generic "text" type, other than say plain ASCII or UniCode files. > Every other "text" file should be of type "Microsoft Word File > Format Text" or "WordPerfect FileFormat Text" or "HTML Text". Hmm. It looks like I may not have quite finished the point I intended to make there... On the Mac there are many files of type "TEXT" which are really some application-specific format. TEXT != TEXT. If we completely abandon the second value (which the MacOS has as a creator field), then we get into a namespace problem. There will be hundreds (thousands?) of developers for Rhapsody, and they will all be dreaming up file-types. You will rapidly run into conflicts, as everyone wants to chose some cool-sounding file type (especially if the file type is user-visible, as it is with file-name extensions). *This* is the problem I'm wondering about. This has not been much of a problem on NeXTSTEP, because (frankly) we haven't had all that many different developers of "public" software (as opposed to internal, "MCCA" applications). We will probably have more Rhapsody developers by December of this year -- before Rhapsody is even officially released -- then we had NeXTSTEP developers in the entire history of the operating system. It would be intelligent of us to at least *think* whether a plan that worked well under NeXTSTEP will work as well when scaled up to the market which we are hoping for Rhapsody. My guess is that things are going to get more awkward, simply due to the number of developers. So, I think it would help if there was a second field, but I wouldn't really call it a creator field. The more I think of it, the more I think it could be a developer field. Thus, all products from "Adobe" would have this developer field set to one value. Adobe could create whatever new file types it needs, without having to worry about a conflict with some shareware or commercial program which they do not know about. I could describe this in better detail, but really I better get to work right now... In any case, I do think that having a single value will not work out as well as splitting it up a bit. This is not to solve file-type issues, it's to solve name-space issues. > > It does make life easier for naming types if the millions of > > little shareware applications do not have to dream up some > > special catchy-looking file type for an application that may > > be abandoned before the year is over. > > That is one reason why NeXT/Apple should come up with a universal > document framework, whereby all OpenStep apps have an easy API > to write/read universal OpenStep files. I think this is too grandiose a scheme to work anytime soon. Some people create new file-types because they don't know any better, but plenty of other developers create new file types because they have a perfectly good reason for having it. If the PICT file type is already defined, you really do want a different file type when you've come up with something like TIFF or JPEG. Thinking that there is going to be some "universal" format which is perfect for all applications is bordering on fantasy, or at least it is if we want Rhapsody released this year. I just do not think it's practical to say "All files are going to be some universal database format, and we'll have the perfect database for all applications implemented by the end of the year". This has been talked about for many years, by people at several companies (including Apple, NeXT, and Be). If it hasn't happened yet (particularly for Be, who has the luxury of starting fresh), then it isn't going to happen by September of this year. I agree that it would be nice, as does everyone who has been talking about it for the last five or ten years, but I do not see it happening in time for the release of Rhapsody. > >> So far I have yet to encounter a scenario where this does not > >> work. > > > >It is easy to imagine scenerios where it will not work out as > >well, and I *like* the way NeXTSTEP works. > > Given the way that NeXT always emphasized working on standard > file types for data that needs to be exchanged between applications. Let me rephrase the above "virtue" of NeXT by just mentioning how few applications (of any type) have been created under NeXTSTEP, in it's history, compared to DOS, Windows, WindowsNT, MacOS, and probably some other operating systems. A lot of things are easier to do if you only have a few people doing them. > For data that is application specific, a unique extension works > equally well as a unique creator id. In either case, duplicates > create problems. In the case of a "developer ID" (which is different than the creator ID of MacOS), duplicates will get a lot less likely. At the very least, shareware authors will know what the "developer ID" of the big commercial developers are, and that alone will make it much less likely to see duplicates. This is a good thing. > > I do not think that the command-line interface is quite as > > important as you make it out here. [...] The first priority, > > in my opinion, is to have a user-friendly GUI interface. If > > you disagree with that, then we just happen to have different > > opinions. > > I guess we do have different opinions. I think neither of the > two is more important, they are of equal importance. I agree that they are equally important, but that is not what the original description implied. The original description implied that files *must* be a certain way for the command-line to work, and that claim is simply not true. You then choose a mapping solution based on your invalid claim, and doing that is definitely a matter of thinking that the command-line is *more* important than the issues of a good GUI environment. > To get back to computers, it is as frustrating for a novice not > to be able to copy a file easily, as it is frustrating for a > power users to have to drag around files for half an hour, if > the same could be acomplished by a shell script in 30 seconds. There is nothing about the other proposals which will make it impossible (or even particularly difficult) to write shell scripts. You're used to using "basename" for a shell script? What's the difference if you have to use a different unix utility ("rhaptype") instead of basename? I am convinced that the shell-writing issue is not going to be a problem for almost any of these ideas, given one or two simple unix utilities. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From gad@eclipse.its.rpi.edu Wed Apr 16 11:33:11 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA27334; Wed, 16 Apr 97 11:33:11 -0700 Received: from eclipse.its.rpi.edu (root@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id OAA33282 for ; Wed, 16 Apr 1997 14:33:03 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA06076; Wed, 16 Apr 97 13:29:30 -0400 Message-Id: <9704161729.AA06076@eclipse.its.rpi.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Wed, 16 Apr 97 13:29:28 -0400 To: Multiple recipients of list Subject: Re: Rhapsody on other hardware (tangent to "Developer communication") References: <9704160808.AA04605@eclipse.its.rpi.edu> <9704160842.AA25005@ kannix.cubiculum.com > > > I'm not sure why your Pentium system does not compare favorably > > to your NeXT hardware, but it's certainly possible to build > > Intel-based hardware which will out-perform NeXT hardware, in > > just about any way you wish to measure performance. > > You didn't get my point: the Pentium DOES outperform the NeXT by > factors ranging from two to ten. However, that does not translate > into user experience, since my NeXT hardware is way fast enough > for all sorts of productivity work. No, you didn't get my point. It is possible to build Intel-based or PPC-based hardware which will outperform NeXT hardware for *any* way you wish to measure performance. *Any* method, including "user experience". Now, you can also build intel hardware with fast-ish chips which is not all that dramatically better than NeXT hardware, but that's getting harder to do as Intel (and PPC) hardware keeps moving forward while our four-year-old NeXT hardware does not change. > We have made BELIEVE by bloat-ware of the MS kind, that we cannot > live without our computers becoming faster by a factor of two > every year. FACT IS that wordprocessing, spreadsheets, e-mail, > code editing, web browsing only can eat up so much CPU horse > power, while the rest of it's time the CPU spends twiddling its > immaginary thumbs. web-browsing is, by itself, causing many computers of all platforms to be upgraded. I already prefer to read web pages from my Mac instead of my NeXT simply because it takes less time. Significantly less time. This is not a question of how good OmniWeb is, it's a question that I'm comparing a 68040-based machine to a 180 MHz PowerPC 604e. More to the point, the number of individual owners of NeXT hardware is small, and it will not grow. Of that small group, many owners will never upgrade to Rhapsody, even if it was available, because they'd rather put their money into other hardware. I don't see any point in Apple spending a lot of time trying to make Rhapsody friendly for hardware which really should be written off at this point. Continue to run NeXTSTEP 3.3patch1 on it. It will be a fine machine for that, but it isn't fine enough to run this year's operating system and all the new software which will be coming. It is rather hypocritical for owners of NeXT hardware to say "I am too cheap to write off a five-year-old computer, so Apple had better spend their time and resources making sure that everything for their new operating system will run on my ancient hardware". I like NeXT hardware (particularly since I own three of them), but I just can't bring myself to even ask Apple to worry about this. I must admit that I *would* like to see NeXTSTEP/SPARC upgraded, so it worked on the latest Sun hardware. > > While various people at Apple have made reassuring comments > > about NeXTSTEP/Intel, nothing much has been said about NeXTSTEP > > on old NeXT hardware. NeXTSTEP on HP hardware is already gone, > > NeXTSTEP on SPARC hardware is nearly useless (because it isn't > > available for most of the hardware Sun actually makes today), > > and I have trouble believing that NeXTSTEP on NeXT hardware is > > going to see all that much more work in upgrades. This is just > > my opinion, don't scream at Apple about it. > > Exactly that constitutes a reason to scream at Apple. If a company > makes a perfectly workable solution unworkable by stopping to > support it, then that warrants screaming. On this particular issue, I think you simply did not understand what I meant when I said that. I said you shouldn't yell at Apple for *MY* opinion. For all I know, Apple *WILL* support NeXT hardware and they (at Apple) all think my opinion is stupid. All I am stating is my opinion. You should find out what Apple itself is going to do before yelling at them. Do not scream at them because of opinions I have expressed. Now, if their opinion is similar to mine, feel free to scream at them for *their* opinion, but not for mine. I do think that the number of people with you are going to be a very very small group compared to the number of people who think Apple will be doing the right thing (or at least, compared to the number of people who will be yelling at Apple to finish on some *other* thing before worrying about Rhapsody on NeXT hardware). --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From jpmorice@mail.club-internet.fr Wed Apr 16 11:48:41 1997 Return-Path: Received: from mailhost.grolier.fr by omnigroup.com (NX5.67f2/NX3.0M) id AA27551; Wed, 16 Apr 97 11:48:41 -0700 Received: from [193.252.136.223] (yellow-bjn1-223.wanadoo.fr [193.252.136.223]) by mailhost.grolier.fr (8.8.5/MGC-960516) with SMTP id UAA23738 for ; Wed, 16 Apr 1997 20:48:32 +0200 (MET DST) Message-Id: <199704161848.UAA23738@mailhost.grolier.fr> Subject: Re: File types in Rhapsody Date: Wed, 16 Apr 97 20:53:04 +0200 X-Sender: jpmorice@mail.club-internet.fr X-Mailer: Claris Emailer 2.0, March 15, 1997 From: Jean-Pierre Morice To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" on 16 apr 97 9:17, Ronald C.F. Antony says : >No, but users should not be punished for wanting to do more. The Mac ties you >down once you have grown wings on a computer. The point is, that I have >yet to find anyone who thinks the NeXT was difficult to use. [snip] >foreach i ( *.tiff ) > mv $i tmp.tiff > tiffutil -lzw tmp.tiff -out $i > rm tmp.tiff >end > >And there it goes. If I had to check the file type by means of some >additional >tool this script would get considerably more complicated, error prone and >difficult to write, i.e. it would require MORE expertise, rather than LESS. >So the computer for "the rest of us" would WIDEN the gap between the >"experts" >and the "novice" rather than narrowing down. > Hmmm... I think you lack contact with Mac advanced features. What about : tell application "Finder" select all files of type "TIFF" set MySelection to the selection end tell tell application "MyCompressor" compress MySelection using LZW protocol end tell Do you really think THAT wording requires MORE expertise than >foreach i ( *.tiff ) > mv $i tmp.tiff > tiffutil -lzw tmp.tiff -out $i > rm tmp.tiff >end ;-) *** jpmorice *** From uucp@cubiculum.com Wed Apr 16 12:19:43 1997 Return-Path: Received: from tunix.cubiculum.com by omnigroup.com (NX5.67f2/NX3.0M) id AA27832; Wed, 16 Apr 97 12:19:43 -0700 Received: by cubiculum.com (NX5.67f2/NX3.0M) id AA03869; Wed, 16 Apr 97 15:19:20 -0400 Received: by kannix.cubiculum.com (NX5.67g/NeXT-2.0) id AA26262; Wed, 16 Apr 97 14:39:38 -0400 Message-Id: <9704161839.AA26262@ kannix.cubiculum.com > Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Face: B6DESMpZ'<"P]D0{Aaq$#h/PfN=wI.C{,&<2_;#|.("xO+oeVic@@=zI2zD#NR~S#l*OV}[ In-Reply-To: <9704161707.AA06023@eclipse.its.rpi.edu> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ronald C.F. Antony Date: Wed, 16 Apr 97 14:39:34 -0400 To: gad@eclipse.its.rpi.edu Subject: Re: File types in Rhapsody Cc: Multiple recipients of list Reply-To: "Ronald C.F. Antony" References: <9704161707.AA06023@eclipse.its.rpi.edu> X-Direct-Marketers: : Add me to your do-not-solicit list >If we completely abandon the second value (which the MacOS has as >a creator field), then we get into a namespace problem. There will >be hundreds (thousands?) of developers for Rhapsody, and they will >all be dreaming up file-types. You will rapidly run into conflicts, >as everyone wants to chose some cool-sounding file type (especially >if the file type is user-visible, as it is with file-name extensions). >*This* is the problem I'm wondering about. That's why NeXT maintained a process by means of which you can register file extensions, the same way as you register domain names. Personally, if internet domain names work for all the entities out there, then file extensions, of which there should be orders of magnitudes less, should work. Even more importantly, how many different applications do people actually use? I mean, who will actually have more than say three different spreadsheets installed? More than five word processors? The chances, that with this you have collisions, are small. Given that windows has by far the most applications, the number of complaints I have heard in regards to file extension collisions are minimal. (I did hear appropriate criticism about some of the implementation details, but that's another issue). Besides, if NeXT/Apple as the registration agent is smart, they assign a pre- or postfix to the extension, unless it's a common standard like .eps, .ai etc. So we could have /some/path/to/filename.fileType_fileSubType e.g. myDoc.txt_msw for a microsoft word text file, and myDoc.txt_frame for a frameMaker text file, or myDoc.txt_wpf for a WordPerfect file. None of this however touches the question if extensions should go away or not. And on that last point, I'm quite clear: they should not go, because that would break cross platform compatibility. >> That is one reason why NeXT/Apple should come up with a universal >> document framework, whereby all OpenStep apps have an easy API >> to write/read universal OpenStep files. > >I think this is too grandiose a scheme to work anytime soon. Some I explicitly called that "future music" and said that this is a long term goal. The goal is as realistic as it gets though. As long as data can be stored as objects (and what data cannot?), it can be stored in an OO-database. If it can be stored in an OO database, we got a universal file format. QED. >I agree that they are equally important, but that is not what >the original description implied. The original description >implied that files *must* be a certain way for the command-line >to work, and that claim is simply not true. You then choose a >mapping solution based on your invalid claim, and doing that is >definitely a matter of thinking that the command-line is *more* >important than the issues of a good GUI environment. What you say is not equality, but submission. If cross platform compatibility is broken, as it would be, then the GUI takes on a position of superior importance. To me that violates the principle of equality... And to make it clear: cross platform compatibility is broken if I can't run my shell scripts on the SGI server down the hall which may happen to store some of my files on an NFS volume. If I'm required to buy Apple's special Unix tools for that server, in order to run my scripts, then we have no longer cross platform compatibility, we are down to the interoperability level... From uucp@cubiculum.com Wed Apr 16 12:19:43 1997 Return-Path: Received: from tunix.cubiculum.com by omnigroup.com (NX5.67f2/NX3.0M) id AA27831; Wed, 16 Apr 97 12:19:43 -0700 Received: by cubiculum.com (NX5.67f2/NX3.0M) id AA03876; Wed, 16 Apr 97 15:19:22 -0400 Received: by kannix.cubiculum.com (NX5.67g/NeXT-2.0) id AA26274; Wed, 16 Apr 97 14:42:00 -0400 Message-Id: <9704161842.AA26274@ kannix.cubiculum.com > Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Face: B6DESMpZ'<"P]D0{Aaq$#h/PfN=wI.C{,&<2_;#|.("xO+oeVic@@=zI2zD#NR~S#l*OV}[ In-Reply-To: X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ronald C.F. Antony Date: Wed, 16 Apr 97 14:41:57 -0400 To: scott_hankin@avid.com Subject: Re: File types in Rhapsody Cc: Multiple recipients of list Reply-To: "Ronald C.F. Antony" References: X-Direct-Marketers: : Add me to your do-not-solicit list >>That's the point. An application (at least in NeXTSTEP/OpenStep speak) is >>a GUI tool, but that does not mesh with scripts. If you think about the >>/bin/file CLI-tool, then it is severely limited. Also e.g. to LZW compress >>all tiff files I can now do this in a shell window: >> >>foreach i ( *.tiff ) >> mv $i tmp.tiff >> tiffutil -lzw tmp.tiff -out $i >> rm tmp.tiff >>end >> >>And there it goes. If I had to check the file type by means of some additional >>tool this script would get considerably more complicated, error prone and >>difficult to write, i.e. it would require MORE expertise, rather than LESS. >>So the computer for "the rest of us" would WIDEN the gap between the "experts" >>and the "novice" rather than narrowing down. > >foreach i (filetype tiff *) > mv $i tmp > tiffutil -lzw tmp -out $i > rm tmp >end That will not work. What you suggest shows that you do not understand how UNIX like shell scripts work. A utility, like the "filetype" one you suggest, produces output to standard out, i.e. a stream. foreach takes arguments, not streams. So to get the standard out of a utility useable as arguments for another program, the whole context has to be backquoted, which in turn may create other problems e.g. that the wild card cannot be immediately interpreted, but would have to be quoted itself... Regardless of that, it kills cross-platform compatibility. Also NeXT/Apple would have to reinvent all the shells that are available today for free, and add support to them, introducing bugs, creating a support nightmare. And yes, compatibility IS a designated goal of the new Apple with NeXT: last I checked there were these words in all the important mission statements: open standards, enterprise computing, cross-platform strategy Open standards e.g. implies the use of POSIX or at least POSIX-like tools and shells, NFS file systems, TCP/IP networking. Enterprise computing implies furthest possible transparency to the execution environment from client to corporate server. Cross-platform strategy means that what they do has to be able to work on Win95, WinNT, DEC-UNIX, HP-UX, etc. >Indeed, I'd expect that utility to be built into the scripting language. Currently there is no scripting language. Now we have no need for an Apple specific scripting language, since we have open standards based shells. I can run sh, csh, tcsh, zsh, ec, scsh, perl, etc. just to name a few. Their workings will break and I would have to rely on whatever Apple cooks up, if Apple were to switch from a high performance open standards based Unix file system, to some proprietary thing that requires all sorts of special support. >You demonstrate considerable expertise when you run tiffutil on any file >whose last four letters happen to be tiff, perhaps more than should be >expected of the non-expert user. The issue is not the last four letters, but all letters trailing the last period in a file name. Hence the script also reads *.tiff and not *tiff The period is integral part of the notation, and is the separator that acts as an accessor notation to metadata. For all intents and purposes, file extensions can be interpreted as a reporting/accessing functionality for metadata, whereby default reports follow a notational convention of adding the filetype ID to the file name, separated by a period, and selection is done with the same accessor function notation, similar to the way C-struct elements are accessed with a . operator. Ultimately it's nothing but a syntax question, which shows why Apple/NeXT could just filter extensions away for display purposes in places like the browser. >I hear similar comments from people using vanilla Unix. People have >different needs and preferences. I fail to see how this supports your >argument. Exactly. But that supports my argument in so far, as that shell users should not suffer from the dictate of non-shell users. For non shell users, extensions can be hidden. Shell users on the other hand rely on them. That's why they are neither a problem for non shell users, but a plus for shell users. Hence they should stay. From uucp@cubiculum.com Wed Apr 16 12:19:49 1997 Return-Path: Received: from tunix.cubiculum.com by omnigroup.com (NX5.67f2/NX3.0M) id AA27838; Wed, 16 Apr 97 12:19:49 -0700 Received: by cubiculum.com (NX5.67f2/NX3.0M) id AA03883; Wed, 16 Apr 97 15:19:24 -0400 Received: by kannix.cubiculum.com (NX5.67g/NeXT-2.0) id AA26365; Wed, 16 Apr 97 15:18:15 -0400 Message-Id: <9704161918.AA26365@ kannix.cubiculum.com > Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Face: B6DESMpZ'<"P]D0{Aaq$#h/PfN=wI.C{,&<2_;#|.("xO+oeVic@@=zI2zD#NR~S#l*OV}[ In-Reply-To: <9704161729.AA06076@eclipse.its.rpi.edu> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ronald C.F. Antony Date: Wed, 16 Apr 97 15:18:12 -0400 To: gad@eclipse.its.rpi.edu Subject: Re: Rhapsody on other hardware (tangent to "Developer communication") Cc: Multiple recipients of list Reply-To: "Ronald C.F. Antony" References: <9704161729.AA06076@eclipse.its.rpi.edu> X-Direct-Marketers: : Add me to your do-not-solicit list >No, you didn't get my point. It is possible to build Intel-based >or PPC-based hardware which will outperform NeXT hardware for *any* >way you wish to measure performance. *Any* method, including "user >experience". Now, you can also build intel hardware with fast-ish >chips which is not all that dramatically better than NeXT hardware, >but that's getting harder to do as Intel (and PPC) hardware keeps >moving forward while our four-year-old NeXT hardware does not >change. I did get the point. But I can't get more than real time scrolling of my text. I can't type faster. Most of the delays in web browsing are due to network constraints and not due to browser limitations. A sound file can only be played back in real time. etc. etc. None of this can be made significantly faster by new hardware. (Unless they change the speed at which my brain and finger work. I guess the NeXT's would not be adequate for Cmd. Data of Star Trek, but that's not me...) If a NeXT machine has enough memory, most of these things run at the maximum speed relevant to a user: real time, without delay. The screen updates only 78 times/second. If I can achieve smooth real time scrolling, what does it help, if the computer were capable of updating the screen 500 times per second? Neither the CRT, nor my eyes could follow... That's what I mean, the user experience does not significantly improve beyond a certain point with current software technology. My NeXT hardware happens to be at that point, because I do not memory starve it. I have worked on really fast machines, (PPro 200, imagine 128, adaptec ultra scsi, with seagate 7200rpm drive and 120 MB RAM) but even though it screams when compiling or crunching numbers, it could not do more than scroll text in real time, follow my keystrokes without perceptible delay, etc. just like my NeXT hardware does. Maybe the scrolling was a trace smoother, maybe the window movements a little less jumpy, but you have to focus on these to even notice the difference. I mean do you really think that window movements in one-pixel increments, rather than two pixel increments is worth a $5000 investment in new hardware, if all you do is word processing and other productivity applications? >More to the point, the number of individual owners of NeXT hardware >is small, and it will not grow. Of that small group, many owners >will never upgrade to Rhapsody, even if it was available, because >they'd rather put their money into other hardware. The same is true for any particular model of Mac's. The same is true for many cars. Nonetheless, that should be part of a manufacturer's planning when introducing products and not be carried out on the customers shoulders a few years down the road. >I don't see any point in Apple spending a lot of time trying to make Rhapsody >friendly for hardware which really should be written off at this >point. If it works, it should not be written off, other than for tax purposes. My NeXTs work JUST FINE, hence I resent the idea that they should be written off, just by virtue of them being five years old. >Continue to run NeXTSTEP 3.3patch1 on it. It will be a >fine machine for that, but it isn't fine enough to run this year's >operating system and all the new software which will be coming. As a matter of fact, I'm running OS4.2PR on it, and it flies. So much for running outdated software on supposedly outdated hardware. Besides, I can't trickle down, if there is no compatiblity. neither OS4.x nor OS3.x will help, if the data and apps aren't compatible with Rhapsody. Besides, anyone with a conscience for environmental issues, should use computers as long as they can fulfill their purpose. The NeXT can, unless axed by Apple. >It is rather hypocritical for owners of NeXT hardware to say "I am >too cheap to write off a five-year-old computer, so Apple had better >spend their time and resources making sure that everything for >their new operating system will run on my ancient hardware". It's not that I'm too cheap. It is that the hardware works. You are brainwashed to belive that hardware manufacturers have the right to expect that you throw out your computers at regular, very short lived intervals. I'm not. I require that a manufacturer supports all his products as long as they have a useful service life. You are the perfect target to have surplus income siphoned away from you by computer and software manufacturers. Given that the NeXT runs current applications just fine, it does have a useful service life. Hence I expect support. Compilers get better, clients get thinner, CPU horsepower gets shifted away from the client to the server. Hence I expect the computer to have a useful service life for several years to come. Greetings, Ronald From uucp@cubiculum.com Wed Apr 16 12:20:31 1997 Return-Path: Received: from tunix.cubiculum.com by omnigroup.com (NX5.67f2/NX3.0M) id AA27855; Wed, 16 Apr 97 12:20:31 -0700 Received: by cubiculum.com (NX5.67f2/NX3.0M) id AA03862; Wed, 16 Apr 97 15:19:17 -0400 Received: by kannix.cubiculum.com (NX5.67g/NeXT-2.0) id AA26335; Wed, 16 Apr 97 15:07:48 -0400 Message-Id: <9704161907.AA26335@ kannix.cubiculum.com > Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) X-Face: B6DESMpZ'<"P]D0{Aaq$#h/PfN=wI.C{,&<2_;#|.("xO+oeVic@@=zI2zD#NR~S#l*OV}[ In-Reply-To: <199704161848.UAA23738@mailhost.grolier.fr> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.148) From: Ronald C.F. Antony Date: Wed, 16 Apr 97 15:07:45 -0400 To: jpmorice@club-internet.fr Subject: Re: File types in Rhapsody Cc: Multiple recipients of list Reply-To: "Ronald C.F. Antony" References: <199704161848.UAA23738@mailhost.grolier.fr> X-Direct-Marketers: : Add me to your do-not-solicit list >Hmmm... I think you lack contact with Mac advanced features. > >What about : > >tell application "Finder" > select all files of type "TIFF" > set MySelection to the selection >end tell > >tell application "MyCompressor" > compress MySelection using LZW protocol >end tell > >Do you really think THAT wording requires MORE expertise than > >>foreach i ( *.tiff ) >> mv $i tmp.tiff >> tiffutil -lzw tmp.tiff -out $i >> rm tmp.tiff >>end For one it is logically more complicated. It could interfere with interactive work, depending on how the pasteboard is implemented, and most certainly, this is not a portable aproach. Try running it on you SUN, or on your file server, etc. It is amazing how many Mac users don't realize why Apple is loosing market share. Computing has moved from a desktop island solution to enterprise wide integration. And while MS may be the evil empire, the way it deals with files and networking is the way every other major OS deals with it. The only system sold in significant numbers that creates hassles like resource and data forks, etc. is the MacOS. And that's why one IS department after the other is anbandoning it: it creates too much trouble when trying to integrate this with a corporate networked environment. Proprietary solutions have a place in home computers like the proposed Pipin, but not in a corporate setting where things have to work with hundreds and thousands of computers of different origin. Apple lives or dies with the people who have money to spend, and that's corporate customers. Apple will not survive on a few graphics artists who have standalone Mac systems and never need to inegrate with other systems other than sending a postscript file to a service bureau... Ronald From gad@eclipse.its.rpi.edu Wed Apr 16 13:12:12 1997 Return-Path: Received: from mail1.its.rpi.edu by omnigroup.com (NX5.67f2/NX3.0M) id AA28586; Wed, 16 Apr 97 13:12:12 -0700 Received: from eclipse.its.rpi.edu (gad@eclipse.its.rpi.edu [128.113.24.33]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id QAA25182 for ; Wed, 16 Apr 1997 16:12:04 -0400 Received: by eclipse.its.rpi.edu (NX5.67e/NX3.0M) id AA06510; Wed, 16 Apr 97 16:12:03 -0400 Message-Id: <9704162012.AA06510@eclipse.its.rpi.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Wed, 16 Apr 97 16:12:01 -0400 To: Multiple recipients of list Subject: Re: Rhapsody on other hardware (tangent to "Developer communication") References: <9704161729.AA06076@eclipse.its.rpi.edu> <9704161918.AA26365@ kannix.cubiculum.com > > > No, you didn't get my point. It is possible to build Intel-based > > or PPC-based hardware which will outperform NeXT hardware for > > *any* way you wish to measure performance. *Any* method, > > including "user experience". > > I did get the point. But I can't get more than real time scrolling > of my text. I can't type faster. Most of the delays in web browsing > are due to network constraints and not due to browser limitations. > A sound file can only be played back in real time. etc. etc. I have a color NeXTstation (well, with a NeXTstation turbo board in it, so it has 96meg of RAM) on my desk here. Right next to it is a PowerMac. They are on the same ethernet. It is a fact that reading web pages on my Mac is unquestionably faster than doing the same pages on my NeXT. Fast enough that most of my web-page reading is done on my Mac, simply because I don't have enough spare time in the day to wait for the web pages I want to read. That is on a NeXT running NeXTSTEP 3.2 (not 4.x, which is more resource-hungry), vs a Mac which is running the latest MacOS, with all the latest add-ons, and is also running an Appleshare file server (the full-blown file server software, not "personal file sharing"), *and* is running with less memory than my NeXTstation. So, I do now think we get each other's point, it's just that our own personal experiences lead us to different conclusions. For me, my NeXTstations are *already* too slow. I see no point in Apple worrying too much about full-blown Rhapsody on NeXT hardware, because I don't see myself buying it. I have NS-4.1, and I do intend to buy NS-4.2, but chances are I'll only be installing that on Intel-based hardware. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From scott_hankin@avid.com Wed Apr 16 13:19:17 1997 Return-Path: Received: from newavid.avid.com by omnigroup.com (NX5.67f2/NX3.0M) id AA28769; Wed, 16 Apr 97 13:19:17 -0700 Received: from [152.165.154.134] by mail.avid.com (SMI-8.6/SMI-SVR4) id QAA02952; Wed, 16 Apr 1997 16:17:49 -0400 X-Sender: shankin@mail.avid.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Apr 1997 16:18:47 -0400 To: rcfa@cubiculum.com From: Scott Hankin Subject: Re: File types in Rhapsody Cc: rhapsody-talk@omnigroup.com >>foreach i (filetype tiff *) >> mv $i tmp >> tiffutil -lzw tmp -out $i >> rm tmp >>end > > That will not work. What you suggest shows that you do not understand how > UNIX like shell scripts work. A utility, like the "filetype" one you > suggest, produces output to standard out, i.e. a stream. foreach takes > arguments, not streams. So to get the standard out of a utility useable as > arguments for another program, the whole context has to be backquoted, > which in turn may create other problems e.g. that the wild card cannot be > immediately interpreted, but would have to be quoted itself... Regardless > of that, it kills cross-platform compatibility. Also NeXT/Apple would have > to reinvent all the shells that are available today for free, and add > support to them, introducing bugs, creating a support nightmare. And yes, > compatibility IS a designated goal of the new Apple with NeXT: last I > checked there were these words in all the important mission statements: What I suggested was not meant to be executable code, but rather to point out that it is possible to support file types without the incredible hassle you claimed it would take to do so. A shell built-in would not require backquotes, and would work as presented. (Aside: my current Unix experience dates back 20 years.) Backwards compatibility is also not the point. I am suggesting something which will work on Rhapsody in order to meet the needs of users. I've never suggested removing existing shells. Rhapsody will have