Comment by ๐ŸŽฒ lab6

Re: "A paradox"

In: s/Gemini

A browser is an interface between protocol and human, running in a context. Even if the protocol never changes, the human and the context can and do.

๐ŸŽฒ lab6

Mar 24 ยท 6 weeks ago

8 Later Comments โ†“

๐Ÿš€ stack ยท Mar 25 at 00:10:

Your question is odd.

Should we be prohibited from writing browsers or servers for that matter?

Is there anything (that other people find fun but you don't) not pointless? Databases? Editors? Compilers? Retrocomputing projects for 50-year old machines? Tennis or chess, where you will never be a world-class player?

Forgive me if I sound harsh, but I honestly don't understand why you think we are done here just because the protocol is simple.

๐Ÿ“ป eugene [OP] ยท Mar 25 at 05:13:

@stack

Should we be prohibited from writing browsers or servers for that matter?

Have I, at any point, made any claims that anything should or should not be done, or that I intend for anything to be forbidden or permitted for anyone? Because I did not, so I can't really see why would you think my *question* requires a reaction like I'm trying to infringe on you.

It's not that "we are done here", but hobby/art projects where the goal is not to advance the field also inherently have no consequence for the field itself. When you are writing software purely for the fun of it, you generally don't expect anyone but you to get any use out of it. In the case where the project implements a particular standard, there's very little to distinguish one implementation from another. (Editors? Nothing is more different than editors, wars have been fought over them for decades.)

Instead of a spec that could potentially evolve, we have a solid crystal, everything actually new meant to work with it has to get a new fancy name.

๐Ÿš€ stack ยท Mar 25 at 15:04:

Don't want to start a fight here, but since you ask why...

You literally said it's pointless to implement a new browser. It's "paradoxical" that any rational being would, since 5 is enough until the end of time.

You are expressing a strong negative opinion. Go to a homebrewing meeting and tell people "It's pointless to brew your own beer, there are at least 5 brands out there". Stop people who are running and tell them running is pointless since they are not going to win any records. Tell stamp collectors their hobby is a useless waste of time.

What kind of a response do you expect?

You absolutely cannot write a real browser in a day, just a toy. You can netcat and dump an html page and call that a browser too, but there is a lot of details that go into a real browser.

๐Ÿš€ lars_the_bear ยท Mar 25 at 16:05:

@stack : I'm not really sure about your brewing example. I wonder if there would be much interest in home brewing, if everybody had to follow exactly the same protocol?

๐Ÿš€ stack ยท Mar 25 at 17:21:

The protocol is the same for making beer. The difference is in the subleties. Same with wine.

A good browser has way more to do with usability and human interface than the text transmission protocol.

๐Ÿš€ lars_the_bear ยท Mar 25 at 17:46:

@stack : fair enough -- I don't know much about brewing beer.

Still, it does seem correct to me to say that -- broadly speaking -- there's less need for a browser to be easy to implement and maintain, if the protocol doesn't change. Sure, you'll have to fix bugs and, sure, people will think of ways to improve the user experience. But we won't have that constant, brutal, relentless maintenance and expansion burden that we have with regular web browsers.

In essence, I'm not sure why "do it in a weekend" was ever a design goal -- even though it goes back to the earliest days of Gemini. And I'm not sure it's realistic, anyway.

๐Ÿš€ mbays ยท Mar 25 at 18:34:

@eugene Reasonable question, but I think you underestimate how many niches for a client there are. The space of possible clients is high-dimensional, so has many extreme points. I can easily think of more than 5 clients none of which is made redundant by another. We have different incompatible UI modes -- graphical, TUI, CLI, with further subdivisions possible, e.g. interactive vs non-interactive CLI. Then niche devices -- e.g. Amigas, e-book readers. Then there are niches for optimising for minimal resource use or minimal installation requirements. I'm sure there are also unexplored possibilities -- audio-only clients, say -- and the future will presumably bring new needs and possibilities.

๐Ÿš€ lars_the_bear ยท Mar 25 at 18:45:

@mbays : I'm sure everything you say is true. And yet I'm not sure I believe that (say) Amiga support was part of the founding intention of Gemini. I think it's more likely that @skyjake is right (in a post on Station, as I recall): by making it easy to write clients, everybody would write one, and this would make it even harder to change the protocol.

While there are going to be niche applications, and there's always work to do to fix bugs and so on, if there had been one decent client for Windows, one for MacOS, and one for Windows, that would have satisfied most people's needs for years to come. There never was a need to write a client in a weekend.

Original Post

๐ŸŒ’ s/Gemini

๐Ÿ“ป eugene:

A paradox โ€” I'm sure that the answer I seek might be found by reading into the archives of the original mailing list, however, I don't have the time for that right now, so I'll have to resort to being wrong in public, surely someone will correct me. So I've been meaning to ask. One of the major stated goals of Gemini is simplicity. A major big idea is to make writing a browser in a high level language easy, and a lot of thought went specifically into making this easy. Another major stated...

๐Ÿ’ฌ 12 comments ยท Mar 24 ยท 6 weeks ago