craig@unicus.UUCP (Craig D. Hubley) (03/01/88)
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)
thomson@utah-cs.UUCP (Richard A Thomson) (03/04/88)
[ Note the follow-up line; I tried to cross post to alt.hypertext, but no go ] In article <2279@unicus.UUCP> craig@unicus.UUCP (Craig D. Hubley) writes: >>ron (rminnich@udel.edu) WRITES: > >> 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. ... >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 [ describes contents of a card data structure ] > A web [ describes contents of a web data structure ] > Craig Hubley, Unicus Corporation, Toronto, Ont. I recently posted a request to alt.hypertext for sources to the 68000 Xanadu server. Why reinvent the wheel with regard to hypermedia systems? The Xanadu Project has been working on the problem for quite some time and they've already implemented a server for the Xanadu System in 68000 code! We can one-up all of Apple's hullabaloo by going straight to the source! With the Xanadu server (it supports the unique identifiers needed for the above data structures through an ingenious system called tumbler arithmetic; see the article by Ted Nelson in the Jan '88 Byte) implemented on the Amiga as a shared library we would be able to accomplish much of the things that have been suggested by the above two articles. More importantly, we would have a direct link to the distributed Xanadu system that promises to make hypermedia so useful. I'm trying to get this server code so that we (the Amiga community) can do something with it. I'm tired of all the MacWeenies gloating over Hype-HypeCard. Lately Apple has been hyping the HypeCard as opening the "doors of desktop video" to the Mac II owners. Who are they kidding? I don't think HypeCard is going to get you desktop video any more than MacPaint gave you color. (i.e. not for a very long time and with much pain) Let's get Xanadu up and running on networked Amigas! Rich Thomson
thomson@utah-cs.UUCP (Richard A Thomson) (03/04/88)
In article <5311@utah-cs.UUCP> thomson@cs.utah.edu.UUCP (Richard A Thomson) writes: >[ Note the follow-up line; I tried to cross post to alt.hypertext, but no go ] > Oops. I just read Bryce's article about comp.sys.amiga.tech, so please disregard the follow-upping to comp.sys.amiga.tech. Apparently alot of you don't have it. Rich Thomson
peter@nuchat.UUCP (Peter da Silva) (03/06/88)
Before you port Xanadu to the Amiga, make sure that it's going to be useful for folks without infinite disk space. I have heard from a couple of people that Xanadu does not allow you to reclaim space taken up by deleted data. While the audit trail this gives you is nice, in the real world where disk space and memory are finite you occasionally have to go back and garbage collect. Has anyone any more data on this subject? By the way, comp.sys.amiga.tech is not real. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
thomson@utah-cs.UUCP (Richard A Thomson) (03/06/88)
In article <736@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >Before you port Xanadu to the Amiga, make sure that it's going to be useful >for folks without infinite disk space. I have heard from a couple of people >that Xanadu does not allow you to reclaim space taken up by deleted data. My impression is that there is a Xanadu protocol that you implement on top of your existing system. There is no reason why an implementation couldn't support deleting modified data. The difference is that you wouldn't have an edit trail, but you can just call the one you've got the "original". I'm not sure how hard it would be to put this into the Xanadu stuff as is, my impression is that your numbers are broadcast to other machines interested in them, so it might cause a problem. >By the way, comp.sys.amiga.tech is not real. Unfortunately I didn't read Bryce's posting until after I posted the article; If you'd looked at the first followup article I posted, this would have been evident. >-- Peter da Silva Rich Thomson
mrr@amanpt1.zone1.com (Mark Rinfret) (03/06/88)
In article <2279@unicus.UUCP>, craig@unicus.UUCP (Craig D. Hubley) writes: > > 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. Are you referring to its implementation (internals) or its outward functionality? > 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... Amen! I would love DEARLY to see a product of the quality of HyperCard or (especially) Owl International's Guide to be implemented on the Amiga. > > And other, hype-less subjects. None of that silly Mac-stackware. Let me start this by saying that I am an avid Amiga owner/fan. However, by day, I work on/with Macintosh systems (Se's and II's). Though the Amiga shines in its collective potential, I still see the Macs doing things that we can't do (or do as well). HyperCard is not to be taken lightly. Though I don't really think of it as a hypertext system, it's one hell of an application generator! Our company president is a guy who hits you with an idea in the morning and wants results by quitting time. He recently approached me with the need to automate our security and guest registration procedures (we are a government contractor). Using HyperCard, I was able to crank out a working demo in a couple of days that blew his socks off! An equivalent application, had I used MPW and C or (Manx and PowerWindows on the Amiga), would still be in design. All too often I see people readily dismiss products on other vendors computers without any firsthand experience. If you get caught up in that, you'll be swept away in the next outgoing tide of obsolescence. I heartily encourage you to continue pushing for hypermedia on the Amiga, however. Though I'm not mentally prepared to engage in a discussion at the moment (going to a dual baptism in 5 minutes - my first grandkids!), I'll be eagerly watching for more discussion. Mark > > Any other proposals for a common Amiga hypertext system ? > Any comments on my ideas ? Anyone think I'm crazy ? > ^^^^^^^^^^^^^^^^^^^^^^^^ Definitely not - just somewhat narrow-minded. -- < Mark R. Rinfret, mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr > < Aquidneck Management Associates Home: 401-846-7639 > < 6 John Clarke Road Work: 401-849-8900 x56 > < Middletown, RI 02840 "If I just had a little more time...">