[tahoe-dev] help: how should you tell a web browser what name to use for a file?

[Brian Warner]

> > Hm...  Maybe that's not the *only* option.  Here's one that I
> > haven't previously considered: use "/@@/" to denote the end of the
> > path and the beginning of the "name for the web browser to use".

Good point. I'm uncertain about making parts of the namespace "magical" like
this, but it's a good option to consider. I don't see how to escape such a
name, though, if some client really wanted to have a subdir or file named
"@@". And escaping strings in general makes me nervous.. you have to be very
clear which places accept which type, or you can run into all sorts of bugs
later on.

> I am increasingly in favor of this option, which is 1.b from ticket  
> #221.  It would look like this:

[abbreviated]

1b: /named/FILEURI/whee.ogg
    /cap/DIRURI/whee.ogg

> What I don't like about this is that people can easily confuse these  
> two, so I hereby offer 1.c, where you can specify a name just for
> the browser to use only when the capability denotes a file, and the
> top- level component is "/named/", and the name for the browser to
> use is separated from the pathname by some special characters,
> perhaps like this:

1c: /named/FILEURI@@name=/whee.ogg

Well, first and foremost, URLs are defined to split on slashes, so we'd
either need to change the specs and code to know that it should strip the
@@name= from the end of a path component before trying to interpret it as a
FILEURI, or we'd need to do something like this intead:

1ca: /named/FILEURI/@@name=/whee.ogg

in which case we're back to the confusion you wanted to avoid earlier,
between these two cases:

 /named/FILEURI/@@name=/whee.ogg
 /cap/DIRURI/@@name=/whee.ogg   (which involves a subdir named "@@name=")

OTOH, we could just say that /named/FILEURI/ can contain an arbitrary number
of intermediate components, all of which are ignored, in which case all of
the following would be equivalent:

1cb: /named/FILEURI/whee.ogg
     /named/FILEURI/@@name=/whee.ogg
     /named/FILEURI/@@@!!!OMG-The-File-Is-Named/whee.ogg

I'm not completely opposed to 1c, but then the goals of #221 start to
infringe upon the FILEURI syntax space (i.e. file-read-caps aren't allowed to
have @@ in them, or have to be a fixed length, or something), and I'd prefer
these to be orthogonal.

> The thing is that people basically never look into the middle of a  
> big ugly URL like that.  Whether is says "uri" or "named" or  
> "helpimtrappedinaurlfactory" will usually make no difference to how  
> people interpret these URLs.
> 
> Hm.  This also suggests that in the new capability encoding that  
> we're going to come up with (nice short capabilities, ticket #217),  
> we should put the character indicating whether this is a directory
> or a file or whatever at the end of the capability rather than at
> the beginning...

If they're as short as we're planning, I think the front would be ok. As a
random data point, when firefox offers to save a file with a long filename,
it shows the beginning of the name, rather than the end.

cheers,
 -Brian