Re: [gopher] You think MIME types is the killer feature ? LOLz
On 5/11/12, Denis Bernard <denis.bernard@laposte.net> wrote:
> Jacob Dahl Pind <rachael@...> writes:
>
>
>> Do you really think the whole +views and ASK parts are described in a
>> meaningful way that facilitated others to make an implementation ?
>
> Oh, yes! My point of view is, as a developer having already published a
> converter from web-log to a gopher-log (nb2gopher), that I planned to
> implement
> something under Gopher+ protocol.
>
> So, my project was to make a converter that could parse an "atom.xml" file
> to
> output a gopher+ menu. You can imagine, I thing, how easily this kind of
> converter could duplicate any web site having an atom.xml file output into
> a gopher hole.
Does nb2gopher create a gopher+ menu? It doesn't seem so from looking
at the code, but I'm not that well versed in fortran. Also,
gopher://oceamer.com runs a non-gopher+ server, so I couldn't check to
verify that your phlogs there worked with gopher+.
> To anybody wishing to create a third gopher protocol: please remember what
> happened between HTML4 and HTML5: 4 different standards of xhtml and a lot
> of
> disturbance for web designers. Please, do not repeat this error!
The problem is, we're already kind of in the between phase. Most
servers handle the URL extension (
gopher://gophernicus.org/0/doc/gopher/hURL.txt ), but at least one
modern server doesn't, which messes with clients that rely on that
behavior. Most servers separate item types from the item in the urls
(fake.org/1/badger) but some don't (fake.org/1badger). The CAPS
extension is fairly widely deployed, and at least one server supports
TITLE attributes. And as I've noted elsewhere, different clients
recognize different item type extensions and many site maintainers
employ different item type extensions for similar items.
It would be a lot easier to work in gopherspace if one knew what to
expect instead of having to worry about the homebrewed variants that
are currently in use.
>
> An other thing: you do not need of hundred implementations of gopher servers
> or
> clients. In the Web world, there is less commonly used web servers (maybe
> 3) than gopher servers in the gopher space!
>From what I've seen in my browsings through gopherspace only bucktooth
and gophernicus are widely deployed. But there are many less popular
web servers besides apache, nginx, and lighthttpd, there are many less
popular but still used gopher servers.
>And, in the Web world, there is in fact not so much clients running their own engine
>(maybe 5?).
Rendering gopher is a much simpler task than rendering
HTML/CSS/Flash/JavaScript/etc, so creating a client from scratch is
relatively trivial.
Again, there are many less popular rendering engines for the web
besides the more popular ones. For gopher, I think Overbite and Lynx
are the only ones that are widely used.
>
> I can understand how exiting is to participate to a RFC.
Yes, it's thrilling to discuss the merits of ';' versus 'v'.
>But think about us, the developers.
Close to everyone on this list has done some coding for gopher. We are
the developers. When folks suggest changes, they're trying to fix
problems they see as developers. When folks argue against those
changes, they're trying to avoid problems they see as developers.
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
Reply to: