Re: [gopher] Clients, capabilities and discoverability
> So on the VMS case it's not just about knowing the separator, but also
> the format. In that path, looking for the rightmost dot would lead us to
> browse
>
> [GOPHER$SOMETHING.SOMETHING.SOMETHING]THEFILE
>
> which still points to a file.
>
> But if the meaning of separator is to remove everything at the right of
> the rightmost separator character (keeping it there), saying the
> separator is "]" would work.
Well, no, it would be needed to breadcrumb it -- the idea being that not
only could the most immediate menu be analyzed, but the entire selector,
so that
/foo/bar/bit/byte.txt
could be seen as
root > foo > bar > bit > byte.txt
and anything up the chain be selectable as a menu. The VMS selector probably
isn't analysable in such a manner simplistically, chiefly because I don't think
[GOPHER$SOMETHING.SOMETHING.SOMETHING]
would have been valid as a selector (but I really don't know). The way out
is not to advertise a PathDelimiter and the client simply does not analyse
the selector, presenting it as
root > [GOPHER$SOMETHING.SOMETHING.SOMETHING]THEFILE
as it does now, effectively. And that's what would certainly happen should
that or any other VMS server raise from the dead, since they would have no
caps file.
> Meanwhile, I'm tempted to find a way to present menus as tress in
> Firefox. I'd try generating a XUL file instead of a HTML one (as
> Overbite does). Provided that it works, I would just need to change the
> HTML generation code at components/protocol.js so that it generates
> XUL. (And then I wonder how easy will it be to provide javascript code
> to make the menu do something...)
You could do that, but you would need to have a more complex relationship
between content level scripts and the chrome protocol object. OverbiteFF
already does content embedding of a sort with inline view (it calls itself
to display content within <div>s and <iframe>s). The same thing could apply
to an XUL view, except that the scripts handling interface would embed what
they get back from the protocol object into itself. To wit, the interface
is a tabula rasa consisting simply of the blank page and base menu. The menu
handler emits links with onClick handlers calling the content scripts to
insert content in their place (i.e., the menu you clicked on, "opening" the
folder and inserting the menu). There is no sense of document in such an
interface, just a single window that expands infinitely limited only by
memory. The inline view system is just a very limited subset of this idea.
For that matter, you could still do it in HTML.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@floodgap.com
-- Maturity is only a short break in adolescence. -- Jules Feiffer ------------
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/gopher-project
Reply to: