Re: [BuildStream] Invalid characters for element names

[Chandan Singh <chandan chandansingh net>]

On Fri, Dec 7, 2018 at 4:35 PM Jürg Billeter <j bitron ch> wrote:
> On Fri, 2018-12-07 at 16:25 +0000, Chandan Singh wrote:
> > On Fri, Dec 7, 2018 at 4:15 PM Sander Striker <s striker striker nl>
> > wrote:
> > > Looking at Bazel which is in a similar space, it seems to allow:
> > >
> > > Target names allow all 7-bit ASCII characters except
> > >   0-31 (control characters)
> > >   58 ':' (colon)
> > >   92 '\' (backslash) - directory separator (on Windows); may be
> > > allowed in the future
> > >   127 (delete)
> >
> > I am wondering if there's a desire to allow non-ASCII characters in
> > filenames, or is limiting it to ASCII good enough? I found a related
> > issue [3] for Bazel requesting to allow any characters, but it's been
> > open for a few years now.
> >
> > Also, if we are staying with ASCII for now, do we want to support
> > extended ASCII?
>
> I don't understand what you're asking. So-called "Extended ASCII" would
> mean not staying with ASCII. Either we support full Unicode/UTF-8 with
> clearly defined exceptions or we support a subset of (7-bit) ASCII
> (e.g., the one that Bazel uses). It doesn't make sense to support any
> of the non-Unicode extensions to ASCII, in my opinion.

Sorry, that was poorly phrased. I meant to ask if we wanted to support
any 8-bit/extended ASCII encodings instead of full Unicode, but I am
guessing the answer to that question is no. That seems sensible to me
as well.

My proposal is that we stay with 7-bit ASCII, with the exception of
following characters (similar to Bazel, minus the backlash):

- control characters (0-31)
- delete (127)
- colon ':' (58)

I would vote to avoid opening the can of worms that is Unicode until
we need it, or someone requests it. Would that be acceptable to folks?

> Jürg

Cheers,
Chandan