[comp.sys.mac] APDA on a disk

keith@Apple.COM (Keith Rollin) (05/19/89)

Most of you by now have probably heard of "Developer Helper:Phil & Dave's
Excellent CD". This is a CD released by Apple Developer Services to the
developers who showed up to the WorldWide Developers Conference last week,
and mailed to all the rest who weren't. It contains many tools, programs, and
files that are invaluable to developing any program.

Response to the CD has been fantastic! Way more than we expected! Demand for
the initial pre-release exceeded our stock (12,000) and 7500 more have to
be printed.

All of this has caused speculation here (at Apple) and on the nets as to what
should be done in the future about this. Many people would like to see more
things come from Apple on CD, and also have them distributed to wider
audiences.

I'd like to avoid most of the discussion on *WHAT* should be distributed, and
to *WHOM* it should be distritbuted; I don't think that there will be many
problems coming up with favorable decisions there. However, what I would like
to start a discussion about is how people would like to see the documentation
handled. Our documentation department writes everything in a word processor,
not in HyperCard, so converting to that medium (or any other for that matter)
would be difficult and time consuming.

So what would people like to see? MS-Word files? Text stashed into HyperCard?
Text stashed into HyperCard with Hypertext links? Perferences on some fancy
search and retrieval engines? "Read me" files in MPW format?

Ideally, whatever is done should be a solution that can be implemented
easily. This is because the gating factor of any CD distribution would be the
time it takes to put the documentation in an easily accessed form.

------------------------------------------------------------------------------
Keith Rollin  ---  Apple Computer, Inc.  ---  Developer Technical Support
INTERNET: keith@apple.com
    UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith
"Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions

oster@dewey.soe.berkeley.edu (David Phillip Oster) (05/19/89)

Apple should finally endorse some file format for fonted text + pictures.
They should also endorse some clipboard format for the same data.  I don't
much care which format apple picks:

(.) Microsoft's Rich Text Format
(.) TEXT + STYL (which is what New Text Edit uses, as a clipboard format)
(.) MacWrite version 2.2

Are all formats that spring to mind. Each has their limitations.
Postscript, or any other format so general that you can write an inifinite
loop "macro" is not a good idea, since programs will need to simply parse
this format into their native format.

But, please endorse _some_ single, well documented format. Issue a few
public domain tools for reading or converting that format. The Macintosh
is less than it could be as a result of this babel.

tim@hoptoad.uucp (Tim Maroney) (05/20/89)

Thanks for asking for ideas, Keith.  Im sure the first one that comes to
my mind is the same as many others':  Include the basic MPW.  I understand
that the third-party compiler developers will scream bloody murder if you
include the C or Pascal compiler, so continue to make those separate
products.

Why include MPW, other than the fact that I'd rather not pay for it?

(1) There is a long tradition of including command language
interpreters with operating systems.  No one else, to my knowledge, has
ever charged for them as a separate product.  (Except as replacements
for the "free" CLI shipped with the OS.)

(2) CD-ROM is the natural medium for shipping a huge product like MPW.
Floppy disks don't make it at this size.

(3) If we can be reasonably sure every developer has MPW, then we can
expect a boom in developer utilities, given a standard environment for
them to execute in.  I would expect a proliferation of both freeware
and payware devloper products compatible with MPW.

(4) It will increase pressure on third-party developers to come up with
versions of their systems that are compatible with MPW Shell, which
will be a boon to those devlopers who want to take advantage of various
wonderful MPW Power Tools.  (I'd be *very* interested in an
MPW-compatible Lightspeed C, for instance.)

(5) No third party developer has a product similar to MPW (as long as
we exclude the compilers from "MPW proper"), so you aren't stepping on
anyone's toes.

(6) Apple makes its money from selling hardware, and the money from MPW
at present is infinitesimal relative to money from computer sales.
Apple can easily absorb this loss.  The only thing it gains from
charging hundreds for low-distribution products like this is many
ruffled feelings and widespread software piracy.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Our newest idol, the Superman, celebrating the death of godhead, may be
 younger than the hills; but he is as old as the shepherds."
    - Shaw, "On Diabolonian Ethics"

siegel@endor.harvard.edu (Rich Siegel) (05/20/89)

In article <7370@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:

>(4) It will increase pressure on third-party developers to come up with
>versions of their systems that are compatible with MPW Shell, which
>will be a boon to those devlopers who want to take advantage of various
>wonderful MPW Power Tools.  (I'd be *very* interested in an
>MPW-compatible Lightspeed C, for instance.)

	The architecture of MPW is incompatible with the design tenets
of LightspeedC (or Lightspeed Pascal, for that matter). For example,
there is no way that the instant-link/instant run cycle can happen,
due to the slowness of the MPW linker. (Not to spit on the quality of
the linker - it's a good one, and it's got some features I could use.)
In addition, the integration of tools to the shell is nowhere near as
tight as it needs to be to maintain the project management and auto-
make facilties, and the editor can't support features like option double-
click to locate a symbol, or the pop-up menus that provide instant
access to #include files.

	These are just examples; I'm not quoting official policy or anything
like that.

>(5) No third party developer has a product similar to MPW (as long as
>we exclude the compilers from "MPW proper"), so you aren't stepping on
>anyone's toes.

	Incorrect. Have you forgotten the Aztec C product from Manx?
It's a command-line interface, with tool and editor support. Very much
like MPW, but not as slick. (Commando's pretty nifty stuff!)

		--Rich



~~~~~~~~~~~~~~~
 Rich Siegel
 Staff Software Developer
 Symantec Corporation, Language Products Group
 Internet: siegel@endor.harvard.edu
 UUCP: ..harvard!endor!siegel

 "She told me to make myself comfortable, so I pulled down my pants
 and sat in the pudding." -Emo Phillips
~~~~~~~~~~~~~~~

dave@suna.CMI.COM (David Halonen) (05/22/89)

I've had access to the Tech Notes in three formats:  paper, MacWrite,
and the HyperCard version.  I seldom look at the paper ones, as it is
hard to quickly find all of what you need.  The MacWrite TechNotes are
on a fileserver. I peruse(sp?) these notes with Gopher(tm) when
looking for specific concerns and this works fairly well.

I would advocate a HyperCard implimentation for "static" text.  Its
already organized (alphabetically, by subject, by number, etc...),
which saves one time when trying to quickly locate relevant
information.

IMHO,
David Halonen, Center for Machine Intelligence, Electronic Data Systems
Ann Arbor, MI  (313) 995-0900
AppleLink: N0548   Internet: dave@suna.cmi.com



-- 
David Halonen, Center for Machine Intelligence, Electronic Data Systems
Ann Arbor, MI  (313) 995-0900
AppleLink: N0548   Internet: dave@suna.cmi.com

milo@ndmath.UUCP (Greg Corson) (05/23/89)

After taking some time to look through the developer helper CD, I have
only a few comments.

1. It needs a better index!  Possiblly a keyword searchable Hypercard stack
   or somthing similar.   Perhaps something like "find-file" but with a    
   pre-generated index so it wouldn't have to search the whole CD.

2. There should be a little more info on the items themselves...just a 
   comment in the GET INFO box would be nice.

3. Many items did not include any real documentation...this makes them almost
   worthless.  For example, RAMdump and ReAnimator had NO documentation at
   all, even to tell you what they were for.  There was also no doc for 
   ADSP (Apple data stream protocol)...it would be nice to at least have a 
   quicky installation doc or better-yet a how-to-use document along the
   lines of the sound manager chapter found elsewhere on the disk.
   The HyperAppleTalk stuff had documentation...but a lot of the rest of
   the stuff did not even have an installation documents.

Overall, the CD is a great idea, but it needs better indexing and needs to
include more documents.

Has anyone at Apple considered supporting the CDA (compound document
archetecture) format for text/graphics files?  This is the format supported
by DEC and other manufacturers.

As far as documentation on a disk...a documentation browser like DEC's
"bookreader" would be a good way to set it up.  It gives you a chapter
based index, click on a chapter to get the text.  There are also hypertext
links to pictures and other sections of the documentation.  ie: click
"see figure one" in the text and you get a window with figure 1.  If it
says See section 3.21  you click on that text and section 3.21 appears.

I'm sure you could do this with hypercard...but it might be difficult to
preserve all the fonts, pictures and styles.  I know the hypercard version
of technotes is all plain text.  The "bookreader" approach leaves in ALL
the original features of the document, typestyles, bold-lightface, 
lines, tables, drawings...etc.  If you are going to put Inside Macintosh on
a CD, it would be a lot more useful if all that information were preserved.

Greg Corson
19141 Summers Drive
South Bend, IN 46637
(219) 277-5306 
{pur-ee,rutgers,uunet}!iuvax!ndmath!milo

ech@pegasus.ATT.COM (Edward C Horvath) (05/24/89)

In article <7370@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>(5) No third party developer has a product similar to MPW (as long as
>we exclude the compilers from "MPW proper"), so you aren't stepping on
>anyone's toes.

In article <1881@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel):
> 	Incorrect. Have you forgotten the Aztec C product from Manx?
> It's a command-line interface, with tool and editor support. Very much
> like MPW, but not as slick. (Commando's pretty nifty stuff!)

I don't speak for Manx, but the Aztec C Shell was developed at least
two years before the MPW Shell; we modified the tools in the Aztec package
to run under MPW precisely so we could leverage off Apple's (considerable)
effort.  Manx continues to ship the Aztec shell with the package for those
who don't want to spend the extra hundreds for the MPW shell.

But I frankly doubt that anyone -- including Jim Goodnow, who wrote the
shell initially -- would weep many tears if they didn't have to maintain
it any longer.  Of course, it's still faster than the MPW shell, but I traded
that for the convenience a long time ago.

=Ned Horvath=

Disclaimer: I don't work for Manx.  I was responsible for the MPW port.

wilkins@jarthur.Claremont.EDU (Mark Wilkins) (05/26/89)

In article <31042@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes:

>So what would people like to see? MS-Word files? Text stashed into HyperCard?
>Text stashed into HyperCard with Hypertext links? Perferences on some fancy
>search and retrieval engines? "Read me" files in MPW format?

  How about implementing one of the WP-based options, like "Read me" MPW
files or something, with a simple HyperCard index stack which would start
off knowing something about the CD's layout and allow the user to pick an
item on which (s)he wants documentation.  Then, the stack would read the
text into a scrollable field.
  That way, someone could browse and double-click on a "Read me" to get
information OR use a HyperCard stack to find needed information.
  Of course, someone would have to create an index and a whole bunch of
applicable keywords for all the stuff on the disk but it would be versatile.

                           -- Mark Wilkins