Path: utzoo!yunexus!unicus!craig From: craig@unicus.UUCP (Craig D. Hubley) Newsgroups: comp.sys.amiga Subject: Amiga Hypercard Message-ID: <2279@unicus.UUCP> Date: 1 Mar 88 10:29:31 GMT Article-I.D.: unicus.2279 Posted: Tue Mar 1 05:29:31 1988 Reply-To: craig@unicus.UUCP (Craig D. Hubley) Organization: Unicus Software Inc., Toronto, Ont. Lines: 153 Well, now that I have your attention :-)... For those of you unfamiliar, Apple's Hypercard is a hypertext system that is more hype than text. Technically, it's a silly piece of goo. However, *marketing-wise*, it's attracting lots of attention. Done right, the hypertext concept could do wonders for a machine like the Amiga and its hordes of creative users... read on... >ron (rminnich@udel.edu) WRITES: >Personally i like to build with tools. But on the other hand >the Unix tool-building methodology has kind of given tools a >bad name lately- the interface from program to program (byte pipe) >is just too lacking to allow you to build an interactive system >from simple tools- at least one that people want to use. Agreed. Not only is it clumsy, but it's not usually lightweight, and it's not transparent (not everything *works* through a pipe). It's meant to build *batch* tools from simpler *batch* tools. Let's leave it for exactly that. > On the other hand the Amiga rom kernel supports a more sophisticated >ipc mechanism. We ought to be able to build tools-based integrated systems! With you... >Take a look at HaiCalc; the bar graph menu item activates a process. >Best recent examples: dnet and/or amigatcp, which allow you to >interact with individual processes which all tied together are more than >the equal of all-in-one programs such as vt100. On Dnet for example >you can have amiga programs emulating different types of terminals >running while you have ftp and/or kermit and/or zmodem running too >(conceivably- no body has written the servers yet!) This is what a message-passing operating system is all about. > Now for a challenge. Can we build a tools-based system that is the >equal of Hypercard in its capabilities. I did not say the same thing, >but something as capable. Hypercard's capabilities are neat, but i >find myself put off by the 'one big program' approach. Can such a system >be built some other way? An interesting challenge, i think. Yes, we can build it in many pieces. Real hypertext systems are usually built on top of several separate editor/viewers. Since the Amiga has IFF standards, these editor/viewers can be very easily designed. Since the IFF was designed for *files* and not necessarily resident memory structures, however, there may be some problems. We need at least standards for these data structures, as IFF and memory resident structures. Then a library to support working with them. A card ------ A name and *unique (throughout the universe) identifier* A version number A collection of IFF `pieces' (a picture, some text, a music score) A list of attributes and values for those attributes. For example, `credibility = 0.5', `source = Minsky67' Locations for each of these pieces. for those, like the score, that do not actually appear, a location for the `link' to appear that activates them. A web ----- A name and *unique (throughout the universe) identifier*, version # A collection of link types (just names, really, for programs to work on) A collection of card identifiers and version numbers last known. Might also need list of filenames on which they reside. A list of the typed links that connect them to each other, as local (from a specific part of the text) or global. An active web determines what links you will see on your card. If you have `Joe's comments' activated, then you will see links to Joe's comments. If not, you won't see them. Linkages are independent of the actual cards. This is more powerful than the idea of hard-linkages, and is essential to supporting hypertext publishing and multi-user browsing systems. The cards can be created and maintained by anyone. They belong to them alone. Everyone else accesses them as read-only entities, unless they have write permission. Note that no write permission is required to build a web. Webs can be static, generated on the fly, or standard. An example of a standard web might be a bibliography: `Bibliography'v12 Source, Citation [Minsky67v1, Hubbard72v8, Jones88v3] Hubbard72--Source-->Minsky67 Jones88--Source-->Minsky67 Minsky67--Citation-->Jones88 Minsky67--Citation-->Hubbard72 When a card changes, its version number is upped. The next time the Bibliography is activated, if I browse Hubbard72, and the *card itself* has been changed, and is now v2, then my bibliography checks to see if the source attribute has changed. If Jones88 is the same v3, then it still references Minsky67. The Web is updated to a new version. Note that this handles global-to-global links, which are independent of card version, very easily. Local-to-global links, which would have to be represented as a position on the card, might physically move around, but that's for the card-viewer/refresher to worry about. Local-to-local links are similar, depending on specific positions in both the source and destination card. >(P.S. and besides, i think the script language is gross- reminds > me of Cobol!) The equivalent to the script language here would be a C library (or Basic, or whatever) that could discover things like `what is the current card', ask things easily from popup menus `regenerate, don't use, last version was?', position and uncover cards, move back and forth along links in a web, etc... People could then contribute small parts that used the library: bibliographer builds bibliography webs. builds a web from source attributes, requesting them and adding them to the card where needed. Builds Citation `back-links', asks user to classify material by keyword or other means, builds links to `index' for each subject. editor helps mark up and suggest improvement. Mouse clicks interpreted as spellcheck, Handy menus with links (to NULL) like `needs more detail' and `need a source for this' and `too long' reviewer helps browse and comment material. Similar to editor, only for reviewing finished material. Mouse clicks interpreted as comment to be made. Handy menus that generate common links for reviewing. All utilities would be expected to run independently, using the shared library, which would contain all the common routines and editors. The library interface would be the major piece of work. Of course, a graphic object language for manipulating cards would be handy. Someone could write one on top of the library. And of course, everyone could contribute cards, hopefully some on useful topics like `how to hack your Amiga's expansion port' or `how to program the blitter'. And other, hype-less subjects. None of that silly Mac-stackware. Any other proposals for a common Amiga hypertext system ? Any comments on my ideas ? Anyone think I'm crazy ? Craig Hubley, Unicus Corporation, Toronto, Ont. craig@Unicus.COM (Internet) {uunet!mnetor, utzoo!utcsri}!unicus!craig (dumb uucp) mnetor!unicus!craig@uunet.uu.net (dumb arpa)