Re: [gopher] You think MIME types is the killer feature ? LOLz
On 2012-05-10, Jacob Dahl Pind wrote:
> you can not be seriours, the document describing gopher+ is far from
> clear and anything but the transmission of sizes, and it was never
> ever widely support by anything, and please dont bring up some client
> that havent been touched by anyone for years.
>
> Gopher+ didnt solve any of the things people have brought up here now.
The idea I got so far is that gopher+ is not being widely used, and that
it was a bit complicated.
Even if gopher+ has a couple features that solve some issues people
would like to see solved, if it's not being widely used, it's probably
better to develop another "extension" that solves those issues in a
simpler way.
One point is that the mime-type field suggested by Cameron, unlike
gopher+ views, would be immediately available in the menu itself, while,
IIRC, gopher+ views had to be requested separately.
The problem with the mime-type field really is that it has to be somehow
incorporated in URLs. An idea, for a start, could be just not including
these in the URLs at all. Not as good, but would still be useful in
gopher menus.
Now, the mime-type field may be better left out of an updated RFC (whose
main purpose could/should be to fix the minor annoyances in the original
one and update the selector list) -- following the points I wrote some
mails ago, we could have:
,----
| What if a revised RFC
|
| - Keeps the initial items, along with the few more that were widely
| adopted for specific formats (e.g. pdf and png)
| - Add new purpose-based item types (image, movie, document, ...) to be
| used for uncommon, not widely used/supported file types
| - Split the "unallocated blocks" of item types in purpose-based regions
| (e.g. new types in the range a-j should be used for images, j-o for
| movies)
`----
The RFC could then say:
Specific formats not listed above [table of "official" item types]
should be served under generic selectors, either '9', the selector
for binary items, or one of the more specific general-purpose binary
selectors 'I' (image), ';' (video) or 'd' (document).
Formats that already have a specific selector listed above should not
be served under any of the generic selectors.
If a new format becomes widely used, type identifiers not listed
above can be assigned to that new format, respecting the following
table: [a list would follow, splitting the whole alphabet of
itemtypes in blocks]
And Cameron's interesting mime/type field could then be used (at least?)
for 9, I, ; and d, even if not included in the standard.
--
Nuno J. Silva (aka njsg)
gopher://sdf-eu.org/1/users/njsg
http://njsg.sdf-eu.org/
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
Reply to: