Oops

[Jecel Assumpcao Jr]

I couldn't resist this small comment -
> >>: Fare
> >: Alaric
> > Say you can send arbitary Scheme objects, you
> > could implement device control like so:
> >
> > Message sent to a scrolling LED display -
> > (set-message! "Hello, world")
> >
> > Devices could also generate messages, which would be relatively
> > human readable for debugging, yet low level enough to be efficient
> > to parse and compact to transmit or store.
> >
> Surely, one of the possible representations for messages should be
> human-readable, yet simple enough to be implemented in debuggers
> for embedded systems (and/or the fallback debugger for an OS such as Tunes).
> SEXP are indeed an excellent candidate, being a good compromise
> between machine- and human- readability. I'm all in for SEXP as
> a standard fall-back unambiguous universal representation.
> However, there is no reason to uselessly waste resources on all devices
> by using it as an ubiquituous low-level protocol.
>    Perhaps you'd like your CPU to talk in Scheme with the memory
> or I/O subsystem, and Superduperfastwwwwiiiiddddeee-SCSI-36 disks
> to directly interpret SEXP. Personally I feel that'd be a terrible waste.
> I mightn't look like so, but I don't disdain performance.

The old PET computer used to talk to its disk drives using BASIC
over its GPIB (IEEE488) bus. And Postscript was designed as a human
readable (and programmable) way to talk to printers. I consider
both these efforts (including using Postscript for windowing -
NeWS and NeXTStep) to have had good results, even if they didn't
really "catch on".

When the ARPAnet was developed, there were so many different
machines that it was obvious the it would take a long time to
develop clients/servers for all of them for any new protocol
that was proposed. So they always did things so a person could
replace a client or server software when needed to get things
going. That is why you can use telnet to manually interact with
SMPT, FTP (most of it), POP3, nntp, http and so on. Newer
protocols have come out of the OSI effort, and have the nasty
tendency to have binary encoding that requires complex software
to make it work. A little more efficient? Yes. But I hope
the Tunes takes into account these older experiences I have
mentioned here.

-- Jecel Mattos de Assumpcao Jr -- mailto: jecel@lsi.usp.br
          http://www.lsi.usp.br/~jecel/merlin.html