Re: Not OK computer:/// [was Re: Should Desktop = Home?]

[Gabriel Bauman <gabe bravenet com>]

On Thu, 2004-10-07 at 08:46 +0200, Alexander Larsson wrote:
> > If no one objects, I will try to find time to make some constructive
> > enquiries. A common addressing scheme for these types of shell locations
> > between free desktops would be great.
> 
> Yes i have some objections.
> 
> a) It'll require large changes to the gnome-vfs internals for little
> reason.

I didn't think it actually would require large changes to the vfs
internals, since the computer:, trash: and applications: -style
locations look like they are pretty much defined and provided by
Nautilus. You can't actually access a file via the computer:/// protocol
using the VFS, for instance - what would be the point? However, you are
probably intimately familiar with the implementation, and I could very
well be wrong.

> b) The proposed items don't even look like uris that gnome-vfs can use.
> Is that second part the hostname? Why is making up hostnames that are
> not hostnames any better than making up uri methods? At least the gnome-
> vfs uris work like rfc uris, even if some are not rfc defined.

Actually, you're incorrect. In a Nautilus location box, try typing
"computer:///". Now try typing "computer:". There is no difference here
- both specify exactly the same protocol. The "///" actually refers to a
*path* to be accessed via the "computer" protocol. This is all exactly
in line with the RFC.

For your reference, have a look at http://www.ietf.org/rfc/rfc1738.txt
section 2.1, where the simplest valid form of a URL is defined as  

	<scheme>:<scheme-specific-part>

It is entirely up to the scheme (protocol) to define what appears in the
scheme-specific part... that is, everything after the colon. Try typing
about:plugins in Mozilla.

> c) We're trying to avoid exposing uris to users anyway, so this
> shouldn't matter to users. And in the cases they are visible, we should
> work to fix that. (But if you do know the uri schemes, surely its a lot
> harder to remember/type these new versions.)

The idea I am putting forward here would simplify things for users to an
extent, but the change would really be more of an organizational one.
Having a single 'scheme' namespace for shell-specific folders does make
sense from a structural perspective, in my view. Better to encourage the
use of a common addressing scheme than make up a new scheme every time
we need a new shell location. Whether or not the user actually sees a
mess of schemes or not doesn't strike me as a good reason to leave
things the way they are.

> d) The fact that we have the "Computer" location in gnome and the exact
> behaviour of it is very much a design decision about how gnome wants its
> desktop to look and work. You'll have a pretty hard time to standardize
> that and make other people use it (you'd turn them into Gnome). 

The meat of what is being put forward here is a standard scheme for
addressing shell folders using URL syntax - 'shell:<shell folder name>'.
It would be nice if the actual names of locations were standard across
kde or gnome, as Rui suggested - but there may not be much crossover in
that department, and that is fine. We'd still benefit.

> And when
> you've done that you've basically frozen that part of Gnome from further
> development forever as we can't change it. Same with "applications://",
> we'll hopefully be trying to get rid of that in 2.10.

The idea with a common namespace is to allow us to be as flexible as we
need to be - inside the namespace. The only part that would be 'frozen'
 would be the scheme. It wouldn't be a big deal to add or remove shell
locations. Even the scheme need only be as 'frozen' as
'applications://', which is being removed, so it can't be frozen that
solidly :)

-- 
Gabriel Bauman