RE: [Groff] [off] micro-typography

[P. Alejandro Lopez-Valencia]

>-----Original Message-----
>From: address@hidden [mailto:address@hidden Behalf Of
>Colin Watson
>Sent: Wednesday, February 13, 2002 8:51 AM
>To: address@hidden
>Subject: Re: [Groff] [off] micro-typography
>
>
>On Wed, Feb 13, 2002 at 01:28:00PM +0100, Thomas Baruchel wrote:
>> On Wed, Feb 13, 2002 at 10:59:06AM +0000, Colin Watson wrote:
>> > You also don't have to worry about whether the co-language can
>> > handle sockets; just connect its stdin and stdout to the pipe/socket
>> > to troff.
>>
>> I don't completely agree. Of course you can do this in many
>cases, but it
>> isn't very clean and therefore you have some exceptions. I
>don't see for
>> the moment an unix language interpreter that couldn't do that,
>but I have in
>> mind the difficulty to do that with the unix 'dc' calculator.
>If you try
>> to launch it from a process and write on its stdin, you will not have
>> the evaluations on stdout.
>
>dc probably won't be able to handle sockets anyway. We have to discount
>languages that can only deal with interactive use on a tty.
>
>> Anyway, it won't be very clean, because your initial script would have
>> to do everything (ie. define macros) BEFORE reading stdin. The script
>> would be much more powerful by using a socket.
>
>I don't see the difference. Reading a socket is just the same as reading
>stdin, but stdin is simpler in many languages and involves less setup.
>

.[rant-begin]
Using sockets is a *baaaad idea*. I, for one, don't want to have any Unix
box I be responsible for, which is hooked to the internet (read: with
barbarians already assaulting at the gate), hijacked by any script kiddy
that uses groff remotely to typeset a Trojan in, or to typeset either the
password file, the kernel or, worse of the worst, the entire filesystem
into oblivion.

If you want such facility with security, use named pipes. I for one think
that it should be an embedded language with some sort of security checking
you can configure at source configuration time. And there is no need to
reinvent the wheel with choices such as python, guile, or perl; hell, even
lua is an alternative, if you are such a masochist.

Of course, choosing an embedded language must be done in terms of the
target audience which is *not* jaded old hackers who got in touch with
computers in the early eighties at the least, that is in times so
Paleolithic to have known *roff as the tool of choice to typeset their
documents, and find that writing programs in VM/CMS pseudo-assembler is
the closest to nirvana one can get while incarnated.

Rather the audience is the whole slew of young ones (and I mean *young
ones*) that are coming into computing and choosing Unix and Unix-like
systems for the reasons that may be political, economical or technical.
Therefore , the language chosen must be intelectually accesible, easy to
learn and write and *readable* if it is to be a higher-level API. If they
do not find *roff to be attractive in the face of the alternatives (TeX,
lout, free office packages such as the one from Sun...), then *roff is
doomed to disappear in the next 5 years as a viable option.

.[rant-end]

Now, I'll take my rhubarb pills and get my bile down a bit. :)

Alejo