🚀 go-pugleaf

From article <18323@topaz.rutgers.edu>, by webber@topaz.rutgers.edu (Webber):

Well, I seem to remember Bob Webber being the person who went to
the trouble to port the appropriate FidoNet to form the net.handicapped 
newsgroup.  Makes me wish to see through the (does it have to be so usual)
net.invective on both sides here.

So Hypercard contents are readily translated to and from Unixbased/other
database compatible formats.  In principle.  And it's a principle many
of us very truly are interested in, in fact in finding ways to make
practical.

If you feel strongly about this, Bob, how about writing a prototype of
a practical compatibility processing system.  It would be interesting, 
I think.  And certainly a very constructive move for the philosophies 
you're espousing.

Two shareware ($10) programs might help. Scriptware Detective converts
scripts to readible objects, hexified where text won't work.  Script
Report is a stack which extracts the scripts out of any stack.

I tried something with them.

Ansel is a pretty interesting and well-done biographical hypertext
document for Ansel Adams.  It's 94k long, and has 3 (only) pictures,
counting the 1/3 page smiling Mr. Adams on the first card.  Script
Report says the scripts to do this are 17k long; it's a version of the
Xreftext method.

Let's think about what this means.  It takes 17k to describe the
unique linkage between information on this stack.  A conversion would
have to replicate a largish subset of Hypertalk language to know what
it means.  Then translate to something meaningful, in a way that another 
hyper text/image system could use.  This linkage description would be
arbitrarily different for most any other stack.

Further, let's consider the information that's linked.  Yes, there are
others writing image compression algorithms, but Bill Atkinson's not
exactly a slouch.  This stack appears to the user as mostly text; its
information is; about 20 screens.  The 2-1/2 screens of pictures, though,
I would estimate take up between 1/4 and 1/2 of the 94k, in their 
compressed form.  Most PD database stacks are much heavier on the
pictures, and seem to run to 250k or so; a bit under an hour's
download time on public nets at 1200 baud.  Many are longer.

This compressed imagery must be decompressed, and then translated to the 
system we want to get to.  Along the way, it's much bigger, at the least.


My first conclusions seem to be that HyperCard may be a very reasonably
efficient format to simply pass the information 'the world' may be
interested in.

If that's accepted, then there's also an existence proof that a reader
of such material isn't an impossible task -- there's a commercial DA
(small, surely < 100k, Mac program) available that does a reportedly
not too complete job of reading stacks.

So maybe we should concentrate on building conversion programs, if
it's accepted that Usenet should be used at all for transferring such
high-context information.

Is that, perhaps, the real question of the debate?  If so, let's say so.

If not, let's throttle stacks, like anything else of size, and see
what we can do with them.   I personally agree with the throttling,
(which we call here, approriately enough for a smile, moderation),
especially considering the size.

And perhaps commercial bbs's are exactly the right place for the 
idiosyncratic nature of many of the stacks I have seen.  It's a lot of info, 
and costs to send.

If so, let's say so.


Clive Steward