From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <20186626cdc2e02ec791f8123554c309@plan9.escet.urjc.es>
To: 9fans@cse.psu.edu
From: Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] starting to agree with you about blanks
Date: Thu,  4 Jul 2002 10:25:06 +0200
Topicbox-Message-UUID: c1645584-eaca-11e9-9e20-41e7f4b1d025

:  I would vote for such a feature.  The kernel and 9P would be freed
:  of filename shackles, the shim would apply the existing rules.
:  Imagine, for example, a shim that would enable a 2nd Edition
:  application to access the 4th Edition filesystem.  Mapping filenames

I see. I have to say it was never my aim to open the door for
any other change. It'd be both horrible and a mess to get the kernel
translate names. I think the blank stuff is horrible enough.

:  to continue with the upas/fs example, here's a function that opens a
:  mailbox and returns a pathname that can be used to access the messages
:  therein:
...
:	openmbox("/mail/box/rog/mbox", "My\x00A0Mailbox", buf);

I now see how this would break.
And agree that by doing it in the servers (in the boundaries as you say)
it can be avoided. 

Do we agree that %q is also breaking this?
Or am I mistaken?